Seite 1 von 9 12345 ... LetzteLetzte
Ergebnis 1 bis 25 von 217

Thema: IT-Talents.de Code Competitions

  1. #1
    Und der Tag wird gut...

    Veteran

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    IT-Talents.de Code Competitions

    Hallo,

    so gut wie jeden Monat finden auf IT-Talents.de Programmierwettbewerbe mit jeweils einem Monatsthema statt.
    So gut wie jeder kann an den Wettbewerben teilnehmen und es gibt Sach- und Geldpreise zu gewinnen und es gibt Feedback zu den Code-Abgaben - das einzige was für die Abgabe und Einreichung an die Jury zu beachten ist, es ist ein Account bei IT-Talents erforderlich.

    Dabei wird jeden Monat ein neues Thema vorgegeben das bearbeitet werden kann. Es ist nicht erforderlich bei jedem Thema mitzumachen um sich zu qualifizieren. Jedes Thema ist ein in sich geschlossener Wettbewerb/Ausschreibung.

    Neben der Vorgabe eines Kernthemas werden gewissen Randvorgaben gegeben, das heißt zum Beispiel das nur gewisse Programmiersprachen erlaubt sind - dies ist allerdings sehr breit gefächert und variiert von Aufgabe zu Aufgabe, aber in der Regel sind es die "üblichen" Verdächtigen mit denen entwickelt werden darf.

    Fragen können in der aller Regel auch eingereicht werden, es gibt auf den unten verlinken Seiten Ansprechpartner zu den Wettbewerben.

    Ab und an sind die Aufgaben mal mit GUI, mal Konsolenanwendungen, mal Web bzw. Mobile-Apps, mal mit Basisdaten oder gar Online-Datenquellen die es anzuzapfen gilt, mal können auch Frameworks verwendet werden und vielem mehr.
    Es gibt gewisse Vorgaben, aber die endgültige Umsetzung und Herangehensweise wie ein Problem zu lösen ist, wird dem Teilnehmer/euch selbst überlassen. Spielraum gibt es in aller Regel auch so das auch Zusatzfeatures mit einfließen können.

    Laufzeit der Wettbewerbe ist immer ein ganzer Monat, Details finden sich aber auf der Seite einer jeweiligen Competition.

    Nach Abgabe von Quellcode bei IT-Talents, wird dieser - wie auch die Features und natürlich auch die Funktionalität, bewertet.
    Dies Erfolgt per Email direkt wie auch die Bekanntgabe ob man gewonnen hat oder nicht.

    ---------------------------------------------

    Ich würde gern an dieser Stelle ein Sammelthema aufmachen, in dem alte und neue Competitions besprochen werden können und man sich vielleicht ein wenig darüber austauscht.
    Selbst wer nicht an den Wettbewerben direkt teilnehmen möchte, kann so vielleicht genaueres darüber erfahren wie andere so eine Aufgabe lösen würden bzw. gelöst haben.

    Veröffentlichung von Quellcode sollte hier nicht erforderlich sein und dies sollte jedem selbst überlassen sein, es wäre jedoch schön wenn man sich über Themen/Competitions austauschen könnte, ob alte oder neue sollte hierbei keine Rolle spielen.

    Es wäre vielleicht auch eine Idee, gemeinsam, alte Competitions nachzuprogrammieren, wer Lust und Zeit hat, auch wenn es dann nichts mehr abzugrasen gibt. Die Herausforderung ein Problem mittels Code zu lösen bzw. bearbeiten zu lassen, bleibt bestehen.

    Nur noch eines ist dazu zu sagen, die Bandbreite der Themen ist recht groß und auch der "Schwierigkeitsgrad" - kommt natürlich auf das allgemeine Verständnis in den Themengebieten an.

    ---------------------------------------------

    Hier die Verlinkungen auf die Seite der Wettbewerbe, zum aktuellen Wettbewerb und zu vorherigen/Archiv - aktuell befindet sich alles auf einer Seite.

    ----

    Genereller Link zu den Competitions-Seite

    ----

    Aktueller Wettbewerb

    ----

    Vorherige Competitions mit Archiv

    ---------------------------------------------

    Viel Spaß, Erfolg und gutes Gelingen!

    Und vielleicht ein paar "hitzige" Diskussionen zu den Themen.
    Geändert von theSplit (08.04.17 um 12:43 Uhr)
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++


  2. #2
    Zeitreisender

    Administrator

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    4.398
    ngb:news Artikel
    13

    Re: IT-Talents.de Code Competitions

    Klingt interessant - wenn sich was rührt kann man den dann auch anpinnen.
    Kannst du vielleich für jeden Monat einen Beitrag für das laufende Thema erstellen? Dann kann man das als Marker grün markieren
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  3. #3

    Code Competition für April 2017: Parsergenerator Markdown

    Den Aprilwettbewerb 2017 finde ich spontan sehr interessant. Es geht darum, einen Parsergenerator von (einer Teilmenge von) Markdown nach HTML zu schreiben.

    Teilmenge heißt: Absätze, Überschriften, Listen, Zitatblöcke, fett, kursiv. Also durchaus ein übersichtlicher Umfang.

    Frameworks zu verwenden ist erlaubt, und das ist der interessante Punkt. Ich suche schon länger nach einem Grund, mal was mit Boost Spirit X3 zu machen. Das würde gut passen. Und die Woche nach Ostern ist Urlaub.

    Im Sinne der hitzigen Diskussion : Was mich ein bisschen gruselt, ist, dass sie schreiben:
    {INPUT}
    Es bietet sich die Verwendung von regulären Ausdrücken (Regular Expressions) an.
    Wir wissen doch:
    I had a problem and tried to solve it with regex. Now I have two problems.
    Quelle: alte Programmiererweisheit
    Für diesen Beitrag bedanken sich Roin, alter_Bekannter, saddy
    Geändert von drfuture (07.05.17 um 11:29 Uhr) Grund: Titel geändert für Inhaltsverzeichnis

  4. #4

    Re: IT-Talents.de Code Competitions

    Bedeutet Framework, daß man dann more/less nur in/out baut?

  5. #5
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    @Stingray:

    So wie ich es verstehe, geht es ja darum einen Parser selbst zu schreiben.

    Das heißt dass das Einlesen von Markup behandelt wird, wie auch die Ausgabe/Umwandlung nach HTML.

    Aber ich würde von fertigen Bibliotheken eher abraten die beispielsweise schon Markdown Parsing implementieren.
    Wenn man das selbst noch bestimmen/aufbauen/definieren muß in einem Framework, sieht es vielleicht wieder anders aus.
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  6. #6

    Re: IT-Talents.de Code Competitions

    Nach Ostern ist Zeit und Urlaub, hab ich gesagt, gell. Also wirds so langsam Zeit für die ersten Überlegungen.

    Das ursprüngliche Markdown ist ja nicht spezifiziert, bzw. die »Spezifikation« ist die ursprüngliche Perl-Implementierung. Einen Parser ohne Spec zu schreiben, macht natürlich wenig Spaß. Und durch Perl-Code mag ich mich genauso wenig graben. Zum Glück gibts CommonMark. An die Spec werde ich mich halten.

    Ein bisschen spec-gestöbert hab ich schon; und wow, Markdown schaut auf Anhieb so extrem simpel aus, aber hat es ganz schön in sich. Intuitiv menschenlesbar ist offenbar ne blöde Anforderung, wenn’s auch eindeutig maschinen-parsebar sein soll. Einen vollständigen CommonMark-Parser zu schreiben, würde in richtig Arbeit ausarten.

    Todo:

    1. Markdown verstehen. Auch wenn die Aufgabe nur einen kleinen Teil davon fordert, will ich mir keine Türen zusperren. Der Parser muss so gebaut sein, dass man ihn möglichst stressfrei erweitern oder Richtung reStructuredText umbauen kann. Weil eigentlich bin ich eher reST- als Markdown-Fan.
    2. Daraus ergeben sich die Details der Datenstruktur (AST: abstract syntax tree), die der Parser erzeugen soll. Auf den Punkt gebracht: es wird ein Baum aus Textschnipseln mit ein paar Annotationen dran. Und ausnahmsweise brauch ich mich nicht mit einem Typsystem in den Quelldaten rumschlagen, das man im C++-Code wieder abbilden wollen würde. Strings, Strings überall.
    3. Parsingstrategie entwicklen. Lässt sich alles in einem Parsingdurchgang abfrühstücken oder brauchts mehrere? Ist Pre-/Postprocessing nötig/sinnvoll? Irgendwo ist jedenfalls ein Grenze, wo man manche Details separat behandeln sollte, weil die Grammatik unnötig kompliziert werden würde, wenn man die dort mit reinpackt.
    4. Grammatik/Parser schreiben, a.k.a. Spaß haben mit Spirit.
    5. Iterator bzw. Visitor schreiben, um über den erzeugten Baum zu laufen. HTML-Ausgabe hinten dran klemmen.


    Technisch wird’s wie schon erwähnt C++ mit Boost Spirit X3. Und wahrscheinlich bietet es sich an, das Projekt in eine eigene Parser-Lib, eine Mini-HTML-Writer-Lib und ein Mini-Kommoandozeilenfrontend zu zerlegen.

    Der erste Code wird aber erst nach Ostern das Licht der Welt erblicken. Bis dahin bin ich mit Eier suchen beschäftigt.

    @Stingray: Ich seh das wie theSplit. Einen vorhandenen Markdown-Parser an einen vorhandenen HTML-Writer zu kleben, ist für die Competition wohl ein bisschen dünn. Sie sagen ja auch in der Überschrift:
    Erstelle Deinen eigenen Markdown-Parser

  7. #7
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Ich werde auch an der Challenge teilnehmen, hier mal meine Gedanken dazu (nicht sonderlich fachlich terminiert ):

    Für meinen Ansatz habe ich es erst einmal so gewählt, dass nicht mit RegEx gearbeitet wird, sondern Zeichen für Zeichen (mach ich komischerweise oft so, hat aber auch ein paar Tücken...) verarbeitet werden. Ist für mich der aktuell einfachste Ansatz, ohne sich ein RegEx ähnliches Library zu schreiben. Ich bin davon auch nicht unbedingt ein Fan um ganz ehrlich zu sein, was RegEx durch seine Zeichenlogik theoretisch "korrektes" Markup voraussetzt um die "Boundaries" der Expression einzuhalten. Bei meinem Ansatz kann ich da vielleicht noch etwas "mogeln" bzw. ausbessern.

    Der Parser ist relativ simpel, was mir aktuell noch aufstößt, ob "WhiteSpace-Stripping" am Zeilenanfang stattfinden soll, um Beispielsweise sicherzustellen das wir immer mit einem "gültigen Wert" anfangen. Also zum Beispiel das die Zeile wirklich mit einem "#" oder "*" oder was auch immer beginnt und nicht mit Leerzeichen vorne weg.

    Dann wäre die Frage, da müsste ich mir einmal die Spezifikation nochmal genauer ansehen, ob solche Zeichen wie die Header ("#") nur am Zeilenanfang auftauchen und gültig sind oder ob diese auch frei im Text auftauchen können und dann "ignoriert" werden. Meines Verständnisses nach werden Headlines ja nicht innerhalb des "Textes" definiert, sondern beispielsweise nur am Zeilenanfang.

    Im weiteren wäre mein Gedanke die Daten "on the fly" auszuwerten - heißt ein einziger Lese- und Schreibvorgang, zwischengespeichert werden aktuell nur die Informationen über die HTML Knoten die vor dem eigentlichen, formatierten, Inhalt eingebunden werden sollen, wie auch die Logik wann ein Element geschlossen wird.

    In der Regel läutet ein Zeilenende, soweit ich das bisher nachvollziehe, auch oftmals ein "Tag"-Ende ein. Ausnahmen wäre aber Paragraphen und Zitate, würde ich meinen - ich glaube aber das Github, zum Beispiel, es irgendwie so handhabt, das für jede Zeile ein neuer "p"-HTMLTag generiert wird, aber da würde ich nochmal die Markup Spezifikation wälzen. Aber entscheident sollte ja hierbei sein, auf die nächste Zeile zu schauen ob "anhängende" Textdaten vorliegen oder ein anderes Markup Element generiert werden soll.

    Ich wollte es aber auch so wie @BrotherJohn handhaben:
    - ein Kommadozeilenprogramm, mit Input und Output Parameter
    - relativ einfacher Parser und Writerlogik (sequentieller Einlesevorgang mit paralleler Ausgabe, MarkupElemente identifizieren, HTML Baum mit linearer Struktur aufbauen und beobachten, HTML Schreiben, Inhalte schreiben, Markup schließen, HTML je nach Fall schließen usw.)

    Als Vorlagen habe ich einmal ein einfaches Dokument erstellt, basierend auf der Erklärungsseite zur Competition, und später nen richtigen Github Text, der zwar mehr Elemente enthält, aber alle gesuchten anzutreffen sind.

    Bei Interesse kann ich das auch mal hier veröffentlichen.

    Ist das einzige Problem das ich für den Wettbewerb anzumerken habe, dass kein Beispiel gemacht wurde mit ein oder zwei Testdateien, einfach um sich daran zu orientieren wie viel Logik erforderlich sein muß. Oder auch noch einen Link zur Markdown Spezifikation oder ähnlichem, man wird ein wenig ins "kalte Wasser" geschmissen.
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  8. #8

    Re: IT-Talents.de Code Competitions

    @theSplit: Es gibt keine wirkliche standardisierte Spezifikation von Markdown "itself". Es gibt ein Dokument vom ursprünglichen Autor, der aber viel offen lässt. Es gibt dann aber noch das RFC 7764, was MultiMarkdown, Github Flavoured Markdown, CommonMark und Pandoc standardisiert(vlt. sogar noch eins mehr...?)

    Aber "ursprünglich" wurde Recht wenig Vorgegeben. Deshalb gibt's ja auch so viele Varianten.
    Du kannst im Prinzip einfach alles stumpf durchparsen und davon ausgehen, dass jemand immer korrekt die Tags(#) setzt, oder aber die Vorgabe machen.
    Da man aber einen Header nicht terminieren/beenden kann, ist es auch durchaus logisch anzunehmen, dass man solche nur am Zeilenanfang valide machen kann, gerade auch weil kein Escaping(``) gegeben ist. Das ist zumindest beim GFM so. Ursprünglich wurde mit # terminiert(wenn man es so wollte.)

    Whitespaces am Zeilenanfang würde ich einfach wie Text behandeln, beim Parsen aber einen Hinweis(WARNING: FILE X LINE X, first char in line is space!) ausgeben. Oder komplett durchweg ignorieren, aber auf keinen Fall rausnehmen.


    Justmy2cents.
    mfg
    Für diesen Beitrag bedankt sich theSplit
    Geändert von darksider3 (15.04.17 um 15:05 Uhr)
    Effiziens ist, wenn ich ein Loch bohre und mein Nachbar auch ein Bild aufhängen kann. ;)
    Redundanz macht wiederholen unnötig.
    quod erat expectandum - Unbekannt
    Veni, vidi,vici - Iulius Caesar

  9. #9
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Habe schon ein ersten Testlauf gemacht und nach einigen Stunden frickeln, lüppt es auch.... das ganze läuft sogar ohne einen Buffer in jeglicher Form - allerdings gibt es Probleme wenn "Markdown" Elemente innerhalb des Textes auftauchen, aber nur "beschrieben" sind.

    Das ganze will ich nur mal Showcasen, wie gut oder schlecht die Erkennung aktuell mit einer "on-the-fly" Parser-Writer Base ist (~300 Zeilen Code bisher, nur ein paar generelle Code-Outline/Kommentare).


    Testinput:

    Code (HTML5):
    1. #Markdown Parser
    2.  
    3. ##Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.
    4. **Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden**
    5.  
    6. #{ABOUT}
    7. Was ist eigentlich ein Parser?
    8.  
    9. Mit **Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt**. In *der Regel wird* also *eine (Text-)Eingabe in eine neue Struktur übersetzt*.
    10. Und so soll es auch bei dieser Code Competition sein. Du sollst einen Parser (=Übersetzer) schreiben, der Markdown-Dokumente in HTML-Quellocde übersetzt.
    11.  
    12. ##{INPUT}
    13. * Es bietet sich die Verwendung von regulären Ausdrücken (Regular Expressions) an.
    14.  
    15. Deine Abgabe soll:
    16.  
    17. * Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).
    18. * Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:
    19.  
    20. Markdown-Zeichen    HMTL-Code
    21. #           h1-Überschrift
    22. ##          h2-Überschrift
    23. *           Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)
    24. **fetter_text**     Ein fett geschriebener Text wird mit zwei Sternen (**) eingeleitet und wieder beendet.
    25. *kursiver_text*     Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet (*)
    26. >           Ein Zitat wird durch ein > am Zeilenanfang eingeleitet
    27. Leerzeile       Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.
    28.  
    29.  
    30. #{REVIEW}
    31.  
    32. **Worauf achten wir bei der Bewertung Deiner Abgabe?**
    33.  
    34. * Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?
    35. * Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?
    36. * Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?
    37. * Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)
    38. * Welche Zusatzfeatures wurden eingebaut?
    39.  
    40. **Wie bewerten wir?**
    41.  
    42. ##{POST}
    43.  

    Output:

    Code (HTML5):
    1. <h1>Markdown Parser</h1>
    2.  
    3. <h2>Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.</h2>
    4. <p><strong>Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden</strong></p>
    5.  
    6. <h1>{ABOUT}</h1>
    7. <p>Was ist eigentlich ein Parser?</p>
    8.  
    9. <p>Mit <strong>Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt</strong>. In <em>der Regel wird</em> also eine (Text-)Eingabe in eine neue Struktur übersetzt.
    10. Und so soll es auch bei dieser Code Competition sein. Du sollst einen Parser (=Übersetzer) schreiben, der Markdown-Dokumente in HTML-Quellocde übersetzt.</p>
    11.  
    12. <h2>{INPUT}</h2>
    13. <ul><li>Es bietet sich die Verwendung von regulären Ausdrücken (Regular Expressions) an.</li></ul>
    14.  
    15. <p>Deine Abgabe soll:</p>
    16.  
    17. <ul><li>Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).</li>
    18. <li>Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:</li></ul>
    19.  
    20. <p>Markdown-Zeichen HMTL-Code
    21. <h1>            h1-Überschrift</h1>
    22. <h2>            h2-Überschrift</h2>
    23. <ul><li>        Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)</li></ul>
    24. <strong>fetter_text</strong>        Ein fett geschriebener Text wird mit zwei Sternen () eingeleitet und wieder beendet.
    25. <em>kursiver_text</em>      Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet ()
    26. <blockquote><pre><code>         Ein Zitat wird durch ein > am Zeilenanfang eingeleitet</code></pre></blockquote>
    27. Leerzeile       Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.</p>
    28.  
    29.  
    30. <h1>{REVIEW}</h1>
    31.  
    32. <p><strong>Worauf achten wir bei der Bewertung Deiner Abgabe?</strong></p>
    33.  
    34. <ul><li>Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?</li>
    35. <li>Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?</li>
    36. <li>Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?</li>
    37. <li>Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)</li>
    38. <li>Welche Zusatzfeatures wurden eingebaut?</li></ul>
    39.  
    40. <p><strong>Wie bewerten wir?</strong></p>
    41.  
    42. <h2>{POST}</h2>
    Schon gut bei finde ich, aber es gibt noch ein paar kleinere Bugs...

    Zum Beispiel die doppelten "em" bzw. "*" im ersten Absatz wie in der Vorlage vereinbart, dort wird nur das erste aktuell ausgewertet.

    PS: Das ganze habe ich aber schon gestern angefangen, aber auch nur für 3 Stunden circa.
    Für diesen Beitrag bedankt sich darksider3
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  10. #10
    visual basic Avatar von GoPro
    Registriert seit
    Jun 2016
    Beiträge
    52

    Re: IT-Talents.de Code Competitions

    Mir scheint, dass der Herausforderung bei Regex liegt, mehr, als da ein paar Ersetzungen in Zeichenketten vorzunehmen.
    Aufzählungen, 2 Arten von Überschriften und Absätze wirken jetzt nicht so furchteinflössend.

    Aber mir ist der Nutzen von Regex nicht so klar. Mir ist das 2 oder 3 mal untergekommen und Dank Internet hat es funktioniert. Aber Wem wird da was durch erleichtert.
    Klar, man kann Filter für Zeichenketten sehr kurz schreiben. Aber für wen lohnt sich der Aufwand?
    Manchmal währe bei Vorlesungen/Vorträgen Steno auch praktisch, aber das werde ich dennoch deswegen nicht lernen.
    Gibt es da Laufzeitvorteile? Ich sehe da eine enorm steile Lernkurve, aber nicht den Nutzen.
    Vielleicht gibt es hier jemanden aus der Praxis, wo ,man das sinnvoll einsetztß
    Make Up Your Mind

  11. #11

    Re: IT-Talents.de Code Competitions

    Dann haben wir ja schonmal zwei recht verschiedene Ansätze. TheSplit konzentriert sich auf den Lowlevel-Parsingprozess und ich mich darauf, eine effiziente Grammatik zu definieren.

    Zum selben Ergebnis müssten wir trotzdem kommen. Zumindest halbwegs. Die Aufgabenstellung hat da echt ein paar Kanten. Weil was da steht, widerspricht in Teilen der Spec. Z.B. dürfen im echten Markdown/CommonMark Blockquotes bis zu drei Leerzeichen vor dem > haben. Die Aufgabe sagt: „am Zeilenanfang“. Andererseits ist so eine oberflächlich ungenaue Beschreibung genau das, was ich in der echten Welt von einem Auftraggeber erwarten würde. Also im Zweifel für den Angeklagten, oder? Dann ist es halt Teil der Aufgabe, mit solchen Unklarheiten zurecht zu kommen.

    @theSplit
    Für 3h Arbeit ist das doch schon sehr ordentlich! Ich hab mir auch ein kleines Testdokument mit Grenzfällen gebaut (siehe unten). Schau doch mal, was dein Parser draus macht.

    Testdokument.md

    Spoiler: 

    Code:
    # Ein Testdokument
    
    Absätze sind die grundlegenden Blockelemente.
    
    Ein neuer Absatz braucht mindestens eine Leerzeile.
    
    
    Mehrere geht genauso und führen zum gleichen Ergebnis.
    
    Einen Absatz darf man beliebig
    umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.
    
    Führende Leerzeichen sind ok
              und werden entfernt.
    
       Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.
    
    Viel Inline-Formatierung ist ja nicht gefordert: **Fett** und *kursiv*. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau*dampf*schifffahrts**kapitäns**mütze.
    
    In der Aufgabe steht nichts von geschachtelter Formatierung, Aber ***fettkursiv*** oder **fett und *kursiv*** ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.
    
    Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In *C++* (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis
    
    Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.
    
    ### Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).
    
    #Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.
    
    # normale H1-Überschrift
    #    genauso normale H1-Überschrift
    # auch eine normale H1 mit optionalem schließenden Hash #
    # auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##
    
    ## normale H2
    ## H2: keine Schließhashes, da nicht per Leerzeichen getrennt####
    ## H2: keine Schließhashes, da noch ## Text danach
    
    Spec sagt: “The opening # character may be indented 0-3 spaces.”
    
     # H1
      # H1
       # H1
        # keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.
    
    Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.
    
    Ein Absatz.
    ## Eine H2
    Noch ein Absatz. ##
    
    Nicht von den Hashes am Ende verwirren lassen!
    
    
    ## > Das hier ist eine interessant formatierte H2-Überschrift <
    
    Und wenn wir schon bei den spitzen Klammern sind:
    
    > Ein Zitatabsatz
    
    Oder umgebrochen:
    
    > Auch das ist
    > ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).
    
    Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.
    
    > Ein einzelner Zitatabsatz
    mit Umbruch.
    
    Man kann das natürlich auch kombinieren:
    
    > Das mit dem Zitieren
    schaut auf Anhieb einfach aus.
    > Isses aber nich. Denn dieser ganze Block hier
    > ist ein einzelner Zitatabsatz.
    
    Leerzeilen trennen Zitate.
    
    > Zitat 1
    
    > Zitat 2
    
    Im Vergleich zu:
    
    > Ein einzelnes Zitat.
    >
    > Es hat zwei Absätze.
    
    Eines noch:
    
    > Das Leerzeichen nach der spitzen Klammer
    >ist optional.
    
    
    ## Listen
    
    Lasst uns Sachen auflisten; weil man mit Listen trotz der *am Zeilenanfang*-Einschränkung sooo viel Mist bauen kann! :D
    
    * eins
    * zwei
    * drei
    
    So weit, so einfach.
    
    * eins
    * **zwei** in fett
    * *drei* in kursiv
    * *Nein, das ist
    * nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.
    
    Folgendes
    
    *ist laut Spec
    *keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!
    
    Apropos Absätze:
    
    * langweiliger kurzer Listenpunkt
    * Der hier ist ein bisschen länglicher.
    
      V.a. hat er einen zweiten Absatz.
    * noch ein Punkt
    * und noch einer
    
    Huch!
    
    *
    
    Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.
    
    Aber Vorsicht! Ein leerer Listenpunkt
    *
    unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.
    
    Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:
    
    *
      Was ist das denn?
    * Na logisch! Ein Listenpunkt mit führender Leerzeile.
    * Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?
    
    Ein leerer Punkt in einer Liste? Logisch:
    
    * eins
    *
    * drei
    
    Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.
    
    * Leerzeilen
    
    * zwischen Listenpunkten
    * sind erlaubt
    
    
    * auch mehrere Leerzeilen
    
    Das da oben ist eine einzelne Liste.
    
    * Die Aufgabenstellung fordert den Listenpunkt *am Zeilenanfang*.
      * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).
    
    Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.


    @GoPro
    Regex sind oft sehr nützlich um kurze Sachen sehr kompakt zu validieren. Z.B. hast du mit
    Code:
    ^[_a-zA-Z][_a-zA-Z0-9]*$
    einen guten Teil der Validierung für einen gültigen C++-Identifier erledigt. Der muss mindestens ein Zeichen lang sein, mit Unterstrich oder Buchstabe anfangen und danach dürften beliebig viele Zeichen aus Unterstrich, Buchstabe oder Zahl folgen. Wenn du das alternativ als Schleife hinschreibst, ist das deutlich länger und weniger lesbar.

    Oder du weißt, dass Zeilen in deinen Serverlogs irgendwo das Datum im Format YYYY-MM-DD enthalten und willst darauf zugreifen (\w ist eine Wortgrenze und \d ist eine Zahl, die runden Klammer ziehen dir das gefundene Pattern als direkt zugreifbare Gruppe raus):
    Code:
    \w(\d{4}-\d{2}-\d{2})\w
    Validierung von E-Mail-Adressen macht man auch gerne mit Regex. Halte ich aber für grenzwertig, weil du solche Regex ohne erweiterte Syntax schon nicht mehr verstehen kannst, die dir Zeilenumbrüche und Kommentare erlaubt.

    Das Laufzeitverhalten kommt ganz auf die Implementierung und die Situation an. Je nachdem kannst du mit Regex sehr schnell oder sehr langsam sein.
    Für diesen Beitrag bedankt sich theSplit

  12. #12
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    @Brother John: Nene, so schnell und gut bin ich auch nicht, insgesamt hab ich gestern ja auch noch 6 Stunden und heute daran gearbeitet, aber bei weitem nicht so schicke "Testaufgaben" erstellt wie du sie dir vorbereitet hast.
    Ich habe es mir relativ einfach gemacht und einen normalen "Markdown" Text bzw. Beispiele zur Hand genommen. Siehe Github und andere Seiten wenn man einfach mal nach "Markdown Example" sucht.

    Also, ich kann dir folgenden Output anbieten:

    Code (HTML5):
    1. <h1> BROTHER JOHNS TESTDOKUMENT ERGEBNIS</h1>
    2.  
    3. <h1> Ein Testdokument</h1>
    4.  
    5. <p>Absätze sind die grundlegenden Blockelemente.</p>
    6.  
    7. <p>Ein neuer Absatz braucht mindestens eine Leerzeile.</p>
    8.  
    9.  
    10. <p>Mehrere geht genauso und führen zum gleichen Ergebnis.</p>
    11.  
    12. <p>Einen Absatz darf man beliebig<br/>
    13. umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.</p>
    14.  
    15. <p>Führende Leerzeichen sind ok<br/>
    16.           und werden entfernt.</p>
    17.  
    18. <p>   Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.</p>
    19.  
    20. <p>Viel Inline-Formatierung ist ja nicht gefordert: <strong>Fett</strong> und <em>kursiv</em>. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau<em>dampf</em>schifffahrts<strong>kapitäns</strong>mütze.</p>
    21.  
    22. <p>In der Aufgabe steht nichts von geschachtelter Formatierung, Aber <strong></strong><em>fettkursiv</em></strong></em> oder <strong>fett und </strong><em>kursiv</em></strong></em> ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.</p>
    23.  
    24. <p>Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In <em>C++</em> (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis</p>
    25.  
    26. <p>Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.</p>
    27.  
    28. <h3> Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).</h3>
    29.  
    30. <h1>Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.</h1>
    31.  
    32. <h1> normale H1-Überschrift</h1>
    33. <h1>    genauso normale H1-Überschrift</h1>
    34. <h1> auch eine normale H1 mit optionalem schließenden Hash #</h1>
    35. <h1> auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##</h1>
    36.  
    37. <h2> normale H2</h2>
    38. <h2> H2: keine Schließhashes, da nicht per Leerzeichen getrennt####</h2>
    39. <h2> H2: keine Schließhashes, da noch ## Text danach</h2>
    40.  
    41. <p>Spec sagt: “The opening # character may be indented 0-3 spaces.”</p>
    42.  
    43. <p> # H1<br/>
    44.   # H1<br/>
    45.    # H1<br/>
    46.     # keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.</p>
    47.  
    48. <p>Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.</p>
    49.  
    50. <p>Ein Absatz.<br/>
    51. <h2> Eine H2</h2>
    52. Noch ein Absatz. ##</p>
    53.  
    54. <p>Nicht von den Hashes am Ende verwirren lassen!</p>
    55.  
    56.  
    57. <h2> > Das hier ist eine interessant formatierte H2-Überschrift <</h2>
    58.  
    59. <p>Und wenn wir schon bei den spitzen Klammern sind:</p>
    60.  
    61. <blockquote><pre><code> Ein Zitatabsatz</code></pre></blockquote>
    62.  
    63. <p>Oder umgebrochen:</p>
    64.  
    65. <blockquote><pre><code> Auch das ist
    66.  ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).</code></pre></blockquote>
    67.  
    68. <p>Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.</p>
    69.  
    70. <blockquote><pre><code> Ein einzelner Zitatabsatz</code></pre></blockquote>
    71. <p>mit Umbruch.</p>
    72.  
    73. <p>Man kann das natürlich auch kombinieren:</p>
    74.  
    75. <blockquote><pre><code> Das mit dem Zitieren</code></pre></blockquote>
    76. <p>schaut auf Anhieb einfach aus.<br/>
    77. <blockquote><pre><code> Isses aber nich. Denn dieser ganze Block hier
    78.  ist ein einzelner Zitatabsatz.</code></pre></blockquote></p>
    79.  
    80. <p>Leerzeilen trennen Zitate.</p>
    81.  
    82. <blockquote><pre><code> Zitat 1</code></pre></blockquote>
    83.  
    84. <blockquote><pre><code> Zitat 2</code></pre></blockquote>
    85.  
    86. <p>Im Vergleich zu:</p>
    87.  
    88. <blockquote><pre><code> Ein einzelnes Zitat.
    89.  
    90.  Es hat zwei Absätze.</code></pre></blockquote>
    91.  
    92. <p>Eines noch:</p>
    93.  
    94. <blockquote><pre><code> Das Leerzeichen nach der spitzen Klammer
    95. ist optional.</code></pre></blockquote>
    96.  
    97.  
    98. <h2> Listen</h2>
    99.  
    100. <p>Lasst uns Sachen auflisten; weil man mit Listen trotz der <em>am Zeilenanfang</em>-Einschränkung sooo viel Mist bauen kann! :D</p>
    101.  
    102. <ul><li>eins</li>
    103. <li>zwei</li>
    104. <li>drei</li></ul>
    105.  
    106. <p>So weit, so einfach.</p>
    107.  
    108. <ul><li>eins</li>
    109. <p><strong></strong><em>zwei</em></strong> in fett</em><br/>
    110. </em>**drei</em> in kursiv<br/>
    111. **Nein, das ist<br/>
    112. <ul><li>nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.</li></ul></p>
    113.  
    114. <p>Folgendes</p>
    115.  
    116. *ist laut Spec
    117. *keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!
    118.  
    119. <p>Apropos Absätze:</p>
    120.  
    121. <ul><li>langweiliger kurzer Listenpunkt</li>
    122. <li>Der hier ist ein bisschen länglicher.</li></ul>
    123.  
    124. <p>  V.a. hat er einen zweiten Absatz.<br/>
    125. <ul><li>noch ein Punkt</li>
    126. <li>und noch einer</li></ul></p>
    127.  
    128. <p>Huch!</p>
    129.  
    130. *
    131.  
    132. <p>Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.</p>
    133.  
    134. <p>Aber Vorsicht! Ein leerer Listenpunkt<br/>
    135. </p>*
    136. <p>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</p>
    137.  
    138. <p>Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:</p>
    139.  
    140. *
    141. <p>  Was ist das denn?<br/>
    142. <ul><li>Na logisch! Ein Listenpunkt mit führender Leerzeile.</li>
    143. <li>Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?</li></ul></p>
    144.  
    145. <p>Ein leerer Punkt in einer Liste? Logisch:</p>
    146.  
    147. <ul><li>eins</li></ul>
    148. *
    149. <li>drei</li></ul>
    150.  
    151. <p>Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.</p>
    152.  
    153. <ul><li>Leerzeilen</li></ul>
    154.  
    155. <li>zwischen Listenpunkten</li>
    156. <li>sind erlaubt</li></ul>
    157.  
    158.  
    159. <li>auch mehrere Leerzeilen</li></ul>
    160.  
    161. <p>Das da oben ist eine einzelne Liste.</p>
    162.  
    163. <ul><li>Die Aufgabenstellung fordert den Listenpunkt <em>am Zeilenanfang</em>.</li></ul>
    164. <p>  * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).</p>
    165.  
    166. <p>Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.</p>
    Im übrigen sehr schön geschrieben *neidisch bin*

    Ich glaube das verwirrenste für meinen Parser, die "Dangling" Sterne - leere Listenelemente (weil nicht nach "newline" geprüft wird, sondern Leerzeichen) und ähnliches um ein Objekt als "valide" zu beschreiben, ansonsten könnte das nämlich auch "kursiver Text" sein + deine gemischte Formatierung.

    Wie du siehst habe ich auch keine White-Space stripping für die Header Elemente, eigentlich bleibt alles "intakt". Kann aber muß nicht gewollt sein, kann man aber auch noch mit einbinden denke ich... zumindest das erste Space nach einer Raute bzw. in Header-Elementen...

    Im Browser werden übrigens die Spaces "ignoriert" die am Anfang der Zeile sind.

    *Edit:
    Hier gibt es auch noch einen guten Überblick was die Elemente eventuell machen können sollten, aber soweit bin ich auch noch nicht

    https://daringfireball.net/projects/markdown/dingus


    *Edit2:

    Und ein Update, jetzt passt es auch mit dem verschachtelten Tags und Bonus aus Brother Johns Testdokument
    Und auch die Orphanen "*" werden auch teilweise einbezogen. Und Zitate werden besser behandelt...


    Code (HTML5):
    1. <h1> BROTHER JOHNS TESTDOKUMENT</h1>
    2.  
    3. <h1> Ein Testdokument</h1>
    4.  
    5. <p>Absätze sind die grundlegenden Blockelemente.</p>
    6.  
    7. <p>Ein neuer Absatz braucht mindestens eine Leerzeile.</p>
    8.  
    9.  
    10. <p>Mehrere geht genauso und führen zum gleichen Ergebnis.</p>
    11.  
    12. <p>Einen Absatz darf man beliebig<br/>
    13. umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.</p>
    14.  
    15. <p>Führende Leerzeichen sind ok<br/>
    16.           und werden entfernt.</p>
    17.  
    18. <p>   Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.</p>
    19.  
    20. <p>Viel Inline-Formatierung ist ja nicht gefordert: <strong>Fett</strong> und <em>kursiv</em>. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau<em>dampf</em>schifffahrts<strong>kapitäns</strong>mütze.</p>
    21.  
    22. <p>In der Aufgabe steht nichts von geschachtelter Formatierung, Aber <strong><em>fettkursiv</em></strong> oder **fett und *kursiv* ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.</p>
    23.  
    24. <p>Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In <em>C++</em> (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis</p>
    25.  
    26. <p>Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.</p>
    27.  
    28. <h3> Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).</h3>
    29.  
    30. <h1>Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.</h1>
    31.  
    32. <h1> normale H1-Überschrift</h1>
    33. <h1>    genauso normale H1-Überschrift</h1>
    34. <h1> auch eine normale H1 mit optionalem schließenden Hash #</h1>
    35. <h1> auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##</h1>
    36.  
    37. <h2> normale H2</h2>
    38. <h2> H2: keine Schließhashes, da nicht per Leerzeichen getrennt####</h2>
    39. <h2> H2: keine Schließhashes, da noch ## Text danach</h2>
    40.  
    41. <p>Spec sagt: “The opening # character may be indented 0-3 spaces.”</p>
    42.  
    43. <p> # H1<br/>
    44.   # H1<br/>
    45.    # H1<br/>
    46.     # keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.</p>
    47.  
    48. <p>Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.</p>
    49.  
    50. <p>Ein Absatz.<br/>
    51. <h2> Eine H2</h2>
    52. Noch ein Absatz. ##</p>
    53.  
    54. <p>Nicht von den Hashes am Ende verwirren lassen!</p>
    55.  
    56.  
    57. <h2> &gt; Das hier ist eine interessant formatierte H2-Überschrift &lt;</h2>
    58.  
    59. <p>Und wenn wir schon bei den spitzen Klammern sind:</p>
    60.  
    61. <blockquote><pre><code> Ein Zitatabsatz</code></pre></blockquote>
    62.  
    63. <p>Oder umgebrochen:</p>
    64.  
    65. <blockquote><pre><code> Auch das ist<br/>
    66.  ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).</code></pre></blockquote>
    67.  
    68. <p>Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.</p>
    69.  
    70. <blockquote><pre><code> Ein einzelner Zitatabsatz<br/>
    71. mit Umbruch.</code></pre></blockquote>
    72.  
    73. <p>Man kann das natürlich auch kombinieren:</p>
    74.  
    75. <blockquote><pre><code> Das mit dem Zitieren<br/>
    76. schaut auf Anhieb einfach aus.<br/>
    77.  Isses aber nich. Denn dieser ganze Block hier<br/>
    78.  ist ein einzelner Zitatabsatz.</code></pre></blockquote>
    79.  
    80. <p>Leerzeilen trennen Zitate.</p>
    81.  
    82. <blockquote><pre><code> Zitat 1</code></pre></blockquote>
    83.  
    84. <blockquote><pre><code> Zitat 2</code></pre></blockquote>
    85.  
    86. <p>Im Vergleich zu:</p>
    87.  
    88. <blockquote><pre><code> Ein einzelnes Zitat.<br/>
    89. <br/>
    90.  Es hat zwei Absätze.</code></pre></blockquote>
    91.  
    92. <p>Eines noch:</p>
    93.  
    94. <blockquote><pre><code> Das Leerzeichen nach der spitzen Klammer<br/>
    95. ist optional.</code></pre></blockquote>
    96.  
    97.  
    98. <h2> Listen</h2>
    99.  
    100. <p>Lasst uns Sachen auflisten; weil man mit Listen trotz der <em>am Zeilenanfang</em>-Einschränkung sooo viel Mist bauen kann! :D</p>
    101.  
    102. <ul><li>eins</li>
    103. <li>zwei</li>
    104. <li>drei</li></ul>
    105.  
    106. <p>So weit, so einfach.</p>
    107.  
    108. <ul><li>eins</li>
    109. <li><strong>zwei</strong> in fett</li>
    110. <ul><li><em>drei</em> in kursiv</li>
    111. <ul><li>*Nein, das ist</li>
    112. <li>nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.</li></ul>
    113.  
    114. <p>Folgendes</p>
    115.  
    116. *ist laut Spec
    117. *keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!
    118.  
    119. <p>Apropos Absätze:</p>
    120.  
    121. <ul><li>langweiliger kurzer Listenpunkt</li>
    122. <li>Der hier ist ein bisschen länglicher.</li></ul>
    123.  
    124. <p>  V.a. hat er einen zweiten Absatz.<br/>
    125. <ul><li>noch ein Punkt</li>
    126. <li>und noch einer</li></ul></p>
    127.  
    128. <p>Huch!</p>
    129.  
    130. <ul><li></li></ul>
    131. <p>Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.</p>
    132.  
    133. <p>Aber Vorsicht! Ein leerer Listenpunkt<br/>
    134. <ul><li>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</li></ul></p>
    135.  
    136. <p>Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:</p>
    137.  
    138. <ul><li>  Was ist das denn?</li>
    139. <li>Na logisch! Ein Listenpunkt mit führender Leerzeile.</li>
    140. <li>Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?</li></ul>
    141.  
    142. <p>Ein leerer Punkt in einer Liste? Logisch:</p>
    143.  
    144. <ul><li>eins</li></ul>
    145. <li>* drei</li></ul>
    146.  
    147. <p>Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.</p>
    148.  
    149. <ul><li>Leerzeilen</li></ul>
    150.  
    151. <li>zwischen Listenpunkten</li>
    152. <li>sind erlaubt</li></ul>
    153.  
    154.  
    155. <li>auch mehrere Leerzeilen</li></ul>
    156.  
    157. <p>Das da oben ist eine einzelne Liste.</p>
    158.  
    159. <ul><li>Die Aufgabenstellung fordert den Listenpunkt <em>am Zeilenanfang</em>.</li></ul>
    160. <p>  * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).</p>
    161.  
    162. <p>Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.</p>
    Geändert von theSplit (16.04.17 um 21:05 Uhr) Grund: Neuer Output mit BrotherJohns Testdokument... v2
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  13. #13
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Auch auf die Gefahr hin, diesen Thread mit meinem Kram zuzuspammen, hier mal der letzte Stand, mit dem ich zufrieden bin:

    Einmal den Input und dann der Output, ich habe mich bewusst nicht nur auf Brother Johns - zum Teil Corner Case Situationen allein bezogen, auch wenn ich sagen muß das mir das Dokument in vielerlei Hinsicht auch die Augen geöffnet hat, was man so noch alles berücksichtigen muß bzw. könnte.

    Ich glaube die verschiedenen Fälle sind ganz gut abgedeckt - und immer noch ohne einen Zeichenpuffer zu verwenden und on-the-fly.

    Wenn daran Interesse besteht würde ich auf manche Punkte eingehen, zum Beispiel warum ich manche Vorschläge die Brother John gegeben hatte, brechen würde oder warum etwas anders aussieht als bei ihm vorgeschlagen.

    Spontan fallen mir zum Beispiel ein:
    - keine Implementierung von fett und kursiv, nur fett, kursive und fettkursiv aber kein Mischen von fett und kursiv
    - Listen innerhalb von Paragraphen - warum sollen Sternchen, die nicht der Formatierung von Textschnitten dienen, anders behandelt werden
    - Zeileumbrüche in Paragraphen, ich setzte zum Beispiel voraus, dass die neue Zeile mit einem Space beginnt, ansonsten haben wir keinen Umbruch - aber wir verwenden den automatischen Umbruch im Browser wenn dieser die Zeile nicht ebenfalls "zusammenführt"
    - Zeilenumbrüche in Zitat-Blöcken, ja, schon drin, aber es gibt auch andere Punkte - zum Beispiel das ein Zitat das mit ">" fortgesetzt wird, zusammenhängt, fehlt dieses, machen wir einen harten Umbruch
    usw...


    Input, das einfachere Testdokument von mir, eines aus dem Web und dem Bruder seins

    Code (HTML5):
    1. #Markdown Parser
    2.  
    3. ##Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.
    4. **Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden**
    5.  
    6. #{ABOUT}
    7. Was ist eigentlich ein Parser?
    8.  
    9. Mit **Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt**. In *der Regel wird* also *eine (Text-)Eingabe in eine neue Struktur übersetzt*.
    10. Und *so **soll** es* auch bei dieser ***Code Competition*** sein. Du sollst **einen Parser (=Übersetzer) schreiben**, der **Markdown-Dokumente in HTML-Quellocde übersetzt**.
    11.  
    12. ##{INPUT}
    13. * Es bietet sich die Verwendung von regulären Ausdrücken (*Regular Expressions*) an.
    14.  
    15. Deine Abgabe soll:
    16.  
    17. * Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).
    18. Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:
    19.  
    20. Markdown-Zeichen    HMTL-Code
    21. #           h1-Überschrift
    22. ##          h2-Überschrift
    23. *           Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)
    24.  
    25. **fetter_text**     Ein fett geschriebener Text wird mit zwei Sternen (**) eingeleitet und wieder beendet.
    26.  
    27. *kursiver_text*     Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet (*)
    28.  
    29. > Ein Zitat wird durch ein > am Zeilenanfang eingeleitet
    30. > Und hier geht das Zitat in eine neue Zeile über
    31.  
    32. Leerzeile       Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.
    33.  
    34.  
    35. #{REVIEW}
    36.  
    37. **Worauf achten wir bei der Bewertung Deiner Abgabe?**
    38.  
    39. * Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?
    40. * Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?
    41. * Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?
    42. * Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)
    43. * Welche Zusatzfeatures wurden eingebaut?
    44.  
    45. **Wie bewerten wir?**
    46.  
    47. ##{POST}
    48.  
    49.  
    50. # NEW CONTENT
    51.  
    52.  
    53. # An exhibit of Markdown
    54.  
    55. This note demonstrates some of what [Markdown][1] is capable of doing.
    56.  
    57. *Note: Feel free to play with this page. Unlike regular notes, this doesn't automatically save itself.*
    58.  
    59. ## Basic formatting
    60.  
    61. Paragraphs can be written like so. A paragraph is the basic block of Markdown. A paragraph is what text will turn into when there is no reason it should become anything else.
    62.  
    63. Paragraphs must be separated by a blank line. Basic formatting of *italics* and **bold** is supported. This *can be **nested** like* so.
    64.  
    65. ## Lists
    66.  
    67. ### Ordered list
    68.  
    69. 1. Item 1
    70. 2. A second item
    71. 3. Number 3
    72. 4. Ⅳ
    73.  
    74. *Note: the fourth item uses the Unicode character for [Roman numeral four][2].*
    75.  
    76. ### Unordered list
    77.  
    78. * An item
    79. * Another item
    80. * Yet another item
    81. * And there's more...
    82.  
    83. ## Paragraph modifiers
    84.  
    85. ### Code block
    86.  
    87.     Code blocks are very useful for developers and other people who look at code or other things that are written in plain text. As you can see, it uses a fixed-width font.
    88.  
    89. You can also make `inline code` to add code into other things.
    90.  
    91. ### Quote
    92.  
    93. > Here is a quote. What this is should be self explanatory. Quotes are automatically indented when they are used.
    94.  
    95. ## Headings
    96.  
    97. There are six levels of headings. They correspond with the six levels of HTML headings. You've probably noticed them already in the page. Each level down uses one more hash character.
    98.  
    99. ### Headings *can* also contain **formatting**
    100.  
    101. ### They can even contain `inline code`
    102.  
    103. Of course, demonstrating what headings look like messes up the structure of the page.
    104.  
    105. I don't recommend using more than three or four levels of headings here, because, when you're smallest heading isn't too small, and you're largest heading isn't too big, and you want each size up to look noticeably larger and more important, there there are only so many sizes that you can use.
    106.  
    107. ## URLs
    108.  
    109. URLs can be made in a handful of ways:
    110.  
    111. * A named link to [MarkItDown][3]. The easiest way to do these is to select what you want to make a link and hit `Ctrl+L`.
    112. * Another named link to [MarkItDown](http://www.markitdown.net/)
    113. * Sometimes you just want a URL like <http://www.markitdown.net/>.
    114.  
    115. ## Horizontal rule
    116.  
    117. A horizontal rule is a line that goes across the middle of the page.
    118.  
    119. ---
    120.  
    121. It's sometimes handy for breaking things up.
    122.  
    123. ## Images
    124.  
    125. Markdown can also contain images. I'll need to add something here sometime.
    126.  
    127. ## Finally
    128.  
    129. There's actually a lot more to Markdown than this. See the official [introduction][4] and [syntax][5] for more information. However, be aware that this is not using the official implementation, and this might work subtly differently in some of the little things.
    130.  
    131.  
    132.   [1]: http://daringfireball.net/projects/markdown/
    133.   [2]: http://www.fileformat.info/info/unicode/char/2163/index.htm
    134.   [3]: http://www.markitdown.net/
    135.   [4]: http://daringfireball.net/projects/markdown/basics
    136.   [5]: http://daringfireball.net/projects/markdown/syntax
    137.  
    138.  
    139.  
    140. #### TEXT
    141.  
    142. It's very easy to make some words **bold** and other words *italic* with Markdown. You can even [link to Google!](http://google.com)
    143.  
    144. #### LISTS
    145.  
    146. Sometimes you want numbered lists:
    147.  
    148. 1. One
    149. 2. Two
    150. 3. Three
    151.  
    152. Sometimes you want bullet points:
    153.  
    154. * Start a line with a star
    155. * Profit!
    156.  
    157. Alternatively,
    158.  
    159. - Dashes work just as well
    160. - And if you have sub points, put two spaces before the dash or star:
    161.   - Like this
    162.   - And this
    163.  
    164. #### HEADINGS AND quote
    165.  
    166. # Structured documents
    167.  
    168. Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.
    169.  
    170. ### This is a third-tier heading
    171.  
    172. You can use one `#` all the way up to `######` six for different heading sizes.
    173.  
    174. If you'd like to quote someone, use the > character before the line:
    175.  
    176. > Coffee. The finest organic suspension ever devised... I beat the Borg with it.
    177. > - Captain Janeway
    178.  
    179.  
    180. # BROTHER JOHNS TESTDOKUMENT
    181.  
    182. # Ein Testdokument
    183.  
    184. Absätze sind die grundlegenden Blockelemente.
    185.  
    186. Ein neuer Absatz braucht mindestens eine Leerzeile.
    187.  
    188.  
    189. Mehrere geht genauso und führen zum gleichen Ergebnis.
    190.  
    191. Einen Absatz darf man beliebig
    192. umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.
    193.  
    194. Führende Leerzeichen sind ok
    195.           und werden entfernt.
    196.  
    197.    Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.
    198.  
    199. Viel Inline-Formatierung ist ja nicht gefordert: **Fett** und *kursiv*. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau*dampf*schifffahrts**kapitäns**mütze.
    200.  
    201. In der Aufgabe steht nichts von geschachtelter Formatierung, Aber ***fettkursiv*** oder **fett und *kursiv*** ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.
    202.  
    203. Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In *C++* (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis
    204.  
    205. Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.
    206.  
    207. ### Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).
    208.  
    209. #Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.
    210.  
    211. # normale H1-Überschrift
    212. #    genauso normale H1-Überschrift
    213. # auch eine normale H1 mit optionalem schließenden Hash #
    214. # auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##
    215.  
    216. ## normale H2
    217. ## H2: keine Schließhashes, da nicht per Leerzeichen getrennt####
    218. ## H2: keine Schließhashes, da noch ## Text danach
    219.  
    220. Spec sagt: “The opening # character may be indented 0-3 spaces.”
    221.  
    222.  # H1
    223.   # H1
    224.    # H1
    225.     # keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.
    226.  
    227. Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.
    228.  
    229. Ein Absatz.
    230. ## Eine H2
    231. Noch ein Absatz. ##
    232.  
    233. Nicht von den Hashes am Ende verwirren lassen!
    234.  
    235.  
    236. ## > Das hier ist eine interessant formatierte H2-Überschrift <
    237.  
    238. Und wenn wir schon bei den spitzen Klammern sind:
    239.  
    240. > Ein Zitatabsatz
    241.  
    242. Oder umgebrochen:
    243.  
    244. > Auch das ist
    245. > ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).
    246.  
    247. Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.
    248.  
    249. > Ein einzelner Zitatabsatz
    250. mit Umbruch.
    251.  
    252. Man kann das natürlich auch kombinieren:
    253.  
    254. > Das mit dem Zitieren
    255. schaut auf Anhieb einfach aus.
    256. > Isses aber nich. Denn dieser ganze Block hier
    257. > ist ein einzelner Zitatabsatz.
    258.  
    259. Leerzeilen trennen Zitate.
    260.  
    261. > Zitat 1
    262.  
    263. > Zitat 2
    264.  
    265. Im Vergleich zu:
    266.  
    267. > Ein einzelnes Zitat.
    268. >
    269. > Es hat zwei Absätze.
    270.  
    271. Eines noch:
    272.  
    273. > Das Leerzeichen nach der spitzen Klammer
    274. >ist optional.
    275.  
    276.  
    277. ## Listen
    278.  
    279. Lasst uns Sachen auflisten; weil man mit Listen trotz der *am Zeilenanfang*-Einschränkung sooo viel Mist bauen kann! :D
    280.  
    281. * eins
    282. * zwei
    283. * drei
    284.  
    285. So weit, so einfach.
    286.  
    287. * eins
    288. * **zwei** in fett
    289. * *drei* in kursiv
    290. * *Nein, das ist
    291. * nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.
    292.  
    293. Folgendes
    294.  
    295. *ist laut Spec
    296. *keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!
    297.  
    298. Apropos Absätze:
    299.  
    300. * langweiliger kurzer Listenpunkt
    301. * Der hier ist ein bisschen länglicher.
    302.  
    303.   V.a. hat er einen zweiten Absatz.
    304. * noch ein Punkt
    305. * und noch einer
    306.  
    307. Huch!
    308.  
    309. *
    310.  
    311. Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.
    312.  
    313. Aber Vorsicht! Ein leerer Listenpunkt
    314. *
    315. unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.
    316.  
    317. Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:
    318.  
    319. *
    320.   Was ist das denn?
    321. * Na logisch! Ein Listenpunkt mit führender Leerzeile.
    322. * Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?
    323.  
    324. Ein leerer Punkt in einer Liste? Logisch:
    325.  
    326. * eins
    327. *
    328. * drei
    329.  
    330. Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.
    331.  
    332. * Leerzeilen
    333.  
    334. * zwischen Listenpunkten
    335. * sind erlaubt
    336.  
    337.  
    338. * auch mehrere Leerzeilen
    339.  
    340. Das da oben ist eine einzelne Liste.
    341.  
    342. * Die Aufgabenstellung fordert den Listenpunkt *am Zeilenanfang*.
    343.   * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).
    344.  
    345. Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.
    346.  

    Und die Ausgabe dazu:

    Code:
    1. <h1>Markdown Parser</h1>
    2.  
    3. <h2>Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.</h2>
    4. <p><strong>Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden</strong></p>
    5.  
    6. <h1>{ABOUT}</h1>
    7. <p>Was ist eigentlich ein Parser?</p>
    8.  
    9. <p>Mit <strong>Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt</strong>. In <em>der Regel wird</em> also <em>eine (Text-)Eingabe in eine neue Struktur übersetzt</em>.
    10. Und <em>so <strong>soll</strong> es</em> auch bei dieser <strong><em>Code Competition</em></strong> sein. Du sollst <strong>einen Parser (=Übersetzer) schreiben</strong>, der <strong>Markdown-Dokumente in HTML-Quellocde übersetzt</strong>.</p>
    11.  
    12. <h2>{INPUT}</h2>
    13. <ul><li>Es bietet sich die Verwendung von regulären Ausdrücken (<em>Regular Expressions</em>) an.</li></ul>
    14.  
    15. <p>Deine Abgabe soll:</p>
    16.  
    17. <ul><li>Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).</li></ul>
    18. <p>Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:</p>
    19.  
    20. <p>Markdown-Zeichen HMTL-Code
    21. <h1>            h1-Überschrift</h1>
    22. <h2>            h2-Überschrift</h2>
    23. <ul><li>            Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)</li></ul></p>
    24.  
    25. <p><strong>fetter_text</strong>     Ein fett geschriebener Text wird mit zwei Sternen (**) eingeleitet und wieder beendet.</p>
    26.  
    27. <p><em>kursiver_text</em>       Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet (*)</p>
    28.  
    29. <blockquote><pre><code> Ein Zitat wird durch ein &gt; am Zeilenanfang eingeleitet<br/>
    30.  Und hier geht das Zitat in eine neue Zeile über</code></pre></blockquote>
    31.  
    32. <p>Leerzeile        Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.</p>
    33.  
    34.  
    35. <h1>{REVIEW}</h1>
    36.  
    37. <p><strong>Worauf achten wir bei der Bewertung Deiner Abgabe?</strong></p>
    38.  
    39. <ul><li>Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?</li>
    40. <li>Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?</li>
    41. <li>Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?</li>
    42. <li>Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)</li>
    43. <li>Welche Zusatzfeatures wurden eingebaut?</li></ul>
    44.  
    45. <p><strong>Wie bewerten wir?</strong></p>
    46.  
    47. <h2>{POST}</h2>
    48.  
    49.  
    50. <h1> NEW CONTENT</h1>
    51.  
    52.  
    53. <h1> An exhibit of Markdown</h1>
    54.  
    55. <p>This note demonstrates some of what [Markdown][1] is capable of doing.</p>
    56.  
    57. <p><em>Note: Feel free to play with this page. Unlike regular notes, this doesn't automatically save itself.</em></p>
    58.  
    59. <h2> Basic formatting</h2>
    60.  
    61. <p>Paragraphs can be written like so. A paragraph is the basic block of Markdown. A paragraph is what text will turn into when there is no reason it should become anything else.</p>
    62.  
    63. <p>Paragraphs must be separated by a blank line. Basic formatting of <em>italics</em> and <strong>bold</strong> is supported. This <em>can be <strong>nested</strong> like</em> so.</p>
    64.  
    65. <h2> Lists</h2>
    66.  
    67. <h3> Ordered list</h3>
    68.  
    69. <p>1. Item 1
    70. 2. A second item
    71. 3. Number 3
    72. 4. Ⅳ</p>
    73.  
    74. <p><em>Note: the fourth item uses the Unicode character for [Roman numeral four][2].</em></p>
    75.  
    76. <h3> Unordered list</h3>
    77.  
    78. <ul><li>An item</li>
    79. <li>Another item</li>
    80. <li>Yet another item</li>
    81. <li>And there's more...</li></ul>
    82.  
    83. <h2> Paragraph modifiers</h2>
    84.  
    85. <h3> Code block</h3>
    86.  
    87. <p>    Code blocks are very useful for developers and other people who look at code or other things that are written in plain text. As you can see, it uses a fixed-width font.</p>
    88.  
    89. <p>You can also make `inline code` to add code into other things.</p>
    90.  
    91. <h3> Quote</h3>
    92.  
    93. <blockquote><pre><code> Here is a quote. What this is should be self explanatory. Quotes are automatically indented when they are used.</code></pre></blockquote>
    94.  
    95. <h2> Headings</h2>
    96.  
    97. <p>There are six levels of headings. They correspond with the six levels of HTML headings. You've probably noticed them already in the page. Each level down uses one more hash character.</p>
    98.  
    99. <h3> Headings <p><em>can</em> also contain <strong>formatting</strong></p></h3>
    100.  
    101. <h3> They can even contain `inline code`</h3>
    102.  
    103. <p>Of course, demonstrating what headings look like messes up the structure of the page.</p>
    104.  
    105. <p>I don't recommend using more than three or four levels of headings here, because, when you're smallest heading isn't too small, and you're largest heading isn't too big, and you want each size up to look noticeably larger and more important, there there are only so many sizes that you can use.</p>
    106.  
    107. <h2> URLs</h2>
    108.  
    109. <p>URLs can be made in a handful of ways:</p>
    110.  
    111. <ul><li>A named link to [MarkItDown][3]. The easiest way to do these is to select what you want to make a link and hit `Ctrl+L`.</li>
    112. <li>Another named link to [MarkItDown](http://www.markitdown.net/)</li>
    113. <li>Sometimes you just want a URL like &lt;http://www.markitdown.net/&gt;.</li></ul>
    114.  
    115. <h2> Horizontal rule</h2>
    116.  
    117. <p>A horizontal rule is a line that goes across the middle of the page.</p>
    118.  
    119. <p>---</p>
    120.  
    121. <p>It's sometimes handy for breaking things up.</p>
    122.  
    123. <h2> Images</h2>
    124.  
    125. <p>Markdown can also contain images. I'll need to add something here sometime.</p>
    126.  
    127. <h2> Finally</h2>
    128.  
    129. <p>There's actually a lot more to Markdown than this. See the official [introduction][4] and [syntax][5] for more information. However, be aware that this is not using the official implementation, and this might work subtly differently in some of the little things.</p>
    130.  
    131.  
    132. <p>  [1]: http://daringfireball.net/projects/markdown/<br/>
    133.   [2]: http://www.fileformat.info/info/unicode/char/2163/index.htm<br/>
    134.   [3]: http://www.markitdown.net/<br/>
    135.   [4]: http://daringfireball.net/projects/markdown/basics<br/>
    136.   [5]: http://daringfireball.net/projects/markdown/syntax</p>
    137.  
    138.  
    139.  
    140. <h4> TEXT</h4>
    141.  
    142. <p>It's very easy to make some words <strong>bold</strong> and other words <em>italic</em> with Markdown. You can even [link to Google!](http://google.com)</p>
    143.  
    144. <h4> LISTS</h4>
    145.  
    146. <p>Sometimes you want numbered lists:</p>
    147.  
    148. <p>1. One
    149. 2. Two
    150. 3. Three</p>
    151.  
    152. <p>Sometimes you want bullet points:</p>
    153.  
    154. <ul><li>Start a line with a star</li>
    155. <li>Profit!</li></ul>
    156.  
    157. <p>Alternatively,</p>
    158.  
    159. <p>- Dashes work just as well
    160. - And if you have sub points, put two spaces before the dash or star:<br/>
    161.   - Like this<br/>
    162.   - And this</p>
    163.  
    164. <h4> HEADINGS AND quote</h4>
    165.  
    166. <h1> Structured documents</h1>
    167.  
    168. <p>Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.</p>
    169.  
    170. <h3> This is a third-tier heading</h3>
    171.  
    172. <p>You can use one `#` all the way up to `######` six for different heading sizes.</p>
    173.  
    174. <p>If you'd like to quote someone, use the &gt; character before the line:</p>
    175.  
    176. <blockquote><pre><code> Coffee. The finest organic suspension ever devised... I beat the Borg with it.<br/>
    177.  - Captain Janeway</code></pre></blockquote>
    178.  
    179.  
    180. <h1> BROTHER JOHNS TESTDOKUMENT</h1>
    181.  
    182. <h1> Ein Testdokument</h1>
    183.  
    184. <p>Absätze sind die grundlegenden Blockelemente.</p>
    185.  
    186. <p>Ein neuer Absatz braucht mindestens eine Leerzeile.</p>
    187.  
    188.  
    189. <p>Mehrere geht genauso und führen zum gleichen Ergebnis.</p>
    190.  
    191. <p>Einen Absatz darf man beliebig
    192. umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.</p>
    193.  
    194. <p>Führende Leerzeichen sind ok<br/>
    195.           und werden entfernt.</p>
    196.  
    197. <p>   Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.</p>
    198.  
    199. <p>Viel Inline-Formatierung ist ja nicht gefordert: <strong>Fett</strong> und <em>kursiv</em>. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau<em>dampf</em>schifffahrts<strong>kapitäns</strong>mütze.</p>
    200.  
    201. <p>In der Aufgabe steht nichts von geschachtelter Formatierung, Aber <strong><em>fettkursiv</em></strong> oder **fett und *kursiv*** ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.</p>
    202.  
    203. <p>Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In <em>C++</em> (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis</p>
    204.  
    205. <p>Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.</p>
    206.  
    207. <h3> Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).</h3>
    208.  
    209. <h1>Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.</h1>
    210.  
    211. <h1> normale H1-Überschrift</h1>
    212. <h1>    genauso normale H1-Überschrift</h1>
    213. <h1> auch eine normale H1 mit optionalem schließenden Hash #</h1>
    214. <h1> auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##</h1>
    215.  
    216. <h2> normale H2</h2>
    217. <h2> H2: keine Schließhashes, da nicht per Leerzeichen getrennt####</h2>
    218. <h2> H2: keine Schließhashes, da noch ## Text danach</h2>
    219.  
    220. <p>Spec sagt: “The opening # character may be indented 0-3 spaces.”</p>
    221.  
    222. <p> # H1<br/>
    223.   # H1<br/>
    224.    # H1<br/>
    225.     # keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.</p>
    226.  
    227. <p>Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.</p>
    228.  
    229. <p>Ein Absatz.
    230. <h2> Eine H2</h2>
    231. Noch ein Absatz. ##</p>
    232.  
    233. <p>Nicht von den Hashes am Ende verwirren lassen!</p>
    234.  
    235.  
    236. <h2> &gt; Das hier ist eine interessant formatierte H2-Überschrift &lt;</h2>
    237.  
    238. <p>Und wenn wir schon bei den spitzen Klammern sind:</p>
    239.  
    240. <blockquote><pre><code> Ein Zitatabsatz</code></pre></blockquote>
    241.  
    242. <p>Oder umgebrochen:</p>
    243.  
    244. <blockquote><pre><code> Auch das ist<br/>
    245.  ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).</code></pre></blockquote>
    246.  
    247. <p>Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.</p>
    248.  
    249. <blockquote><pre><code> Ein einzelner Zitatabsatz
    250. mit Umbruch.</code></pre></blockquote>
    251.  
    252. <p>Man kann das natürlich auch kombinieren:</p>
    253.  
    254. <blockquote><pre><code> Das mit dem Zitieren
    255. schaut auf Anhieb einfach aus.<br/>
    256.  Isses aber nich. Denn dieser ganze Block hier<br/>
    257.  ist ein einzelner Zitatabsatz.</code></pre></blockquote>
    258.  
    259. <p>Leerzeilen trennen Zitate.</p>
    260.  
    261. <blockquote><pre><code> Zitat 1</code></pre></blockquote>
    262.  
    263. <blockquote><pre><code> Zitat 2</code></pre></blockquote>
    264.  
    265. <p>Im Vergleich zu:</p>
    266.  
    267. <blockquote><pre><code> Ein einzelnes Zitat.<br/>
    268. <br/>
    269.  Es hat zwei Absätze.</code></pre></blockquote>
    270.  
    271. <p>Eines noch:</p>
    272.  
    273. <blockquote><pre><code> Das Leerzeichen nach der spitzen Klammer<br/>
    274. ist optional.</code></pre></blockquote>
    275.  
    276.  
    277. <h2> Listen</h2>
    278.  
    279. <p>Lasst uns Sachen auflisten; weil man mit Listen trotz der <em>am Zeilenanfang</em>-Einschränkung sooo viel Mist bauen kann! :D</p>
    280.  
    281. <ul><li>eins</li>
    282. <li>zwei</li>
    283. <li>drei</li></ul>
    284.  
    285. <p>So weit, so einfach.</p>
    286.  
    287. <ul><li>eins</li>
    288. <li><strong>zwei</strong> in fett</li>
    289. <li><em>drei</em> in kursiv</li>
    290. <li>*Nein, das ist</li>
    291. <li>nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.</li></ul>
    292.  
    293. <p>Folgendes</p>
    294.  
    295. <p>*ist laut Spec
    296. *keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!</p>
    297.  
    298. <p>Apropos Absätze:</p>
    299.  
    300. <ul><li>langweiliger kurzer Listenpunkt</li>
    301. <li>Der hier ist ein bisschen länglicher.</li></ul>
    302.  
    303. <p>  V.a. hat er einen zweiten Absatz.
    304. <ul><li>noch ein Punkt</li>
    305. <li>und noch einer</li></ul></p>
    306.  
    307. <p>Huch!</p>
    308.  
    309. <ul><li></li></ul>
    310.  
    311. <p>Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.</p>
    312.  
    313. <p>Aber Vorsicht! Ein leerer Listenpunkt
    314. </p><ul><li></li></ul>
    315. <p>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</p>
    316.  
    317. <p>Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:</p>
    318.  
    319. <ul><li></li></ul>
    320. <p>  Was ist das denn?
    321. <ul><li>Na logisch! Ein Listenpunkt mit führender Leerzeile.</li>
    322. <li>Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?</li></ul></p>
    323.  
    324. <p>Ein leerer Punkt in einer Liste? Logisch:</p>
    325.  
    326. <ul><li>eins</li>
    327. <li></li>
    328. <li>drei</li></ul>
    329.  
    330. <p>Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.</p>
    331.  
    332. <ul><li>Leerzeilen</li></ul>
    333.  
    334. <ul><li>zwischen Listenpunkten</li>
    335. <li>sind erlaubt</li></ul>
    336.  
    337.  
    338. <ul><li>auch mehrere Leerzeilen</li></ul>
    339.  
    340. <p>Das da oben ist eine einzelne Liste.</p>
    341.  
    342. <ul><li>Die Aufgabenstellung fordert den Listenpunkt <em>am Zeilenanfang</em>.</li></ul>
    343. <p>  * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).</p>
    344.  
    345. <p>Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.</p>

    Feedback ist natürlich willkommen

    PS: Die Formatierung ist bestimmt weg, weil die Daten sehr lang sind....

    Und ein Case fehlt noch aktuell, sehe ich gerade:
    Code (HTML5):
    1. <p>Aber Vorsicht! Ein leerer Listenpunkt
    2. </p><ul><li></li></ul>
    3. <p>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</p>
    Der Paragraph wird noch geschlossen und ein neuer eröffnent, irgendwie sollte das ja zusammenhängen....
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  14. #14

    Re: IT-Talents.de Code Competitions

    Zitat Zitat von theSplit
    Auch auf die Gefahr hin, diesen Thread mit meinem Kram zuzuspammen
    Hey, es war/ist Osterwochenende. Die Menschheit ist noch mit Eier finden, Bauchumfang erhöhen und Verwandtschaft tätscheln beschäftigt. Da kannst du an Postingfrequenz nix weltbewegendes erwarten. Bei mir hat sichs inzwischen ausgeostert und ich werde wohl heute Abend die ersten Zeilen Code tippseln.

    Zitat Zitat von theSplit
    Ich glaube die verschiedenen Fälle sind ganz gut abgedeckt
    Finde ich auch. Wenn du simples und vernünftiges Markdown fütterst, kommst du ziemlich weit. Gerade bei den Listen-Grenzfällen ist der WTF-Faktor ja oft schon hoch. Warum sollte jemand solches Zeug in seinen Live-Dokumenten haben?

    Ein paar Gedanken, die mir beim Output durchscrollen kamen:

    • Dass du Whitespace nicht konsequent putzt, finde ich ok mit Fußnote. Und zwar ist es ok bei *dieser* Architektur, wo du bewusst keine Flexibilität beim Ausgabeformat eingebaut hast. HTML ist gesetzt, und dann ist auch die Argumentation vollkommen ok, Dinge nicht zu tun, die der Browser (oder sagen wir: eine HTML-Render-Engine) sowieso übernimmt.
    • Im Post von gestern fällt mir schon folgendes auf: Auch wenn manche Konstrukte deinen Parser grob durcheinander gebracht haben, hat er sich immer wieder relativ flott gefangen und einen neuen Einstiegspunkt gefunden, von dem aus es korrekt weiter ging. Das deutet stark darauf hin, dass deine grundsätzliche Herangehensweise solide ist.
    • Alle Zitate sind als <blockquote><pre><code> ausgezeichnet. Aber ein Zitat ist doch weder zwingend pre-formatted noch ein Codeblock. …
    • Die <br/> finde ich ein bisschen inkonsequent gesetzt. Zumindest in meinem Testdok dürfte kein einziges vorkommen. Harte br-Zeilenumbrüche sind nach ursprünglichem Gruber-Markdown nur Zeilen mit 2+ Leerzeichen am Ende. CommonMark hat alternativ den Backslash eingeführt. Beides hatte ich nicht drin.
    • Bei den Listen, ja da ist viel fieses Zeug dabei. Kann ich v.a. für ne Wettbewerbsaufgabe verstehen, dass du da einige Stellen abschneidest. Wie würdest du’s einschätzen: Die ganzen Sonderfälle spec-konform zu verarbeiten, ist das einfach nur geradlinige Implementierarbeit oder müsstest du an deine Architektur nochmal ran?


    Ganz allgemein: Dass Markdown so ein fluffiges, oft beliebiges Format ist, macht das Parsen nicht einfacher. Das einzig wahre Markdown gibts halt nicht, und weil ja auch die Aufgabenstellung Bedingungen stellt, die von Grubers ursprünglicher Perl-Implementierung abweichen, parsen wir eh nur sowas ähnliches wie Markdown. Prinzipiell ist jedes Detail diskutabel. Deswegen halte ich die CommonMark-Spec so hoch: Es ist zwar nicht ganz Ur-Markdown (was auch immer genau das ist), aber es ist die beste und professionellste komplette Spezifikation, die wir haben. Deswegen würde ich’s im Zweifel so machen, wie es dort steht.

  15. #15
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Zitat Zitat von Brother John Beitrag anzeigen
    Hey, es war/ist Osterwochenende. Die Menschheit ist noch mit Eier finden, Bauchumfang erhöhen und Verwandtschaft tätscheln beschäftigt. Da kannst du an Postingfrequenz nix weltbewegendes erwarten. Bei mir hat sichs inzwischen ausgeostert und ich werde wohl heute Abend die ersten Zeilen Code tippseln.
    Ich muß herzlich darüber lachen.... das nenn ich Sinn für Humor.

    Im großen und ganzen habe ich mich an das Markdown von John Gruber orientiert.
    https://daringfireball.net/projects/markdown

    bzw. auch hier der Cheat Sheet:
    https://daringfireball.net/projects/markdown/dingus

    Das "blockquote pre code"-Konstrukt hatte ich irgendwo im Netz gefunden, ich glaube es war w3schools... da ich das Zitat-HTML-Element bisher selten bis gar nicht verwendet habe, hatte ich dies einfach "übernommen".
    Es wären aber nur zwei Strings in einer Liste/Array die man abändern muß und man hätte dann zum Beispiel "blockquote p" oder nur "blockquote", zum Beispiel, als Wrapper für den Inhalt. Aber ich sehe gerade auch, selbst auf w3schools (ja nicht die beste Seite dafür.... aber komischerweise poppt die Seite immer wieder auf wenn man nach so etwas sucht) - wird aber auch "nur" blockquote verwendet.

    Whitespace-Stripping am Anfang der Zeile, hier könnte man die Regel einführen dass das erste Leerzeichen einer Zeile bzw. nach einem Element "übergangen" wird. Jenes wäre schnell implementiert.

    Die <br/> folgend allerdings einer bzw. zwei festen Regel für Paragraphen und Zitaten, dort wird zum Beispiel überprüft ob die nächste Zeile ein Leerzeichen enthält oder nicht, bzw. ob wir einen Quote-Markdown haben das zu einem Zitat gehört. Anders wäre zum Beispiel ein Quote Element mit mehreren Leerzeilen innerhalb des Zitats nicht möglich gewesen.
    Ansonsten bleibt, zumindest in Firefox, der Aufbau erhalten, so das zum Beispiel ein zusammenhängender Zitatsatz, der über zwei Zeilen geht, auch nicht nur auf eine Zeile geschrieben wird. Was an dem <pre> liegen könnte das ich verwendet habe, dass müsste ich nochmal prüfen.

    Wo ich aber nicht ein Fan von bin, zwei Leerzeichen am Ende eines Textes, mancher "Code"-Editor hat ja zum Beispiel den Befehl, Whitespace am Ende einer Zeile zu entfernen, daher halte ich diese Formatierung für nicht zeitgemäß oder gar sicher, weil es auch nicht optisch hervor sticht - es sei denn man lässt derartige "Symbole" abbilden im Text. Zum Beispiel Notepad++ macht/kann das. Über einen Backslash könnte man allerdings reden, halte ich für die einzig "sichere" und praktikabel anwendbare Variante, oder man verlässt sich auf "mein", leider ein wenig intransparentes, System mit dem Leerzeichen am Zeilenanfang in Paragraphen und Zitaten bzw. auch ob man ">" verwendet (ist eine Abfrage und da müsste ich nochmal ohne "pre" schauen, was mehr Sinn macht).

    Mit den Listen war es gar nicht so schwer, es sieht nur kompliziert aus. Ich speichere zum Beispiel ob ein offener "<ul><li>" besteht, ob es sich um ein "Eltern" oder "kind" Element/Knoten handelt und auch wichtig, ob die Liste schon beendet wurde. Zum Beispiel wenn eine Liste nach einer anderen erstellt wird aber diese nicht zusammenhängen, da kann man nicht nur allein darauf schauen ob nicht schon ein "<ul><li>" verfügbar wäre.

    Und um auf deine Frage einzugehen: Nach welcher Spec richtet man sich (CommonMark müsste ich mal googlen) und was genau stellst du dir darunter vor, welche "Sonderfälle", sowas wie genestete Listen und andere Elemente die nicht in der Aufgabe stehen?

    *Update:
    Also das "pre" hat nichts daran gerüttelt das Zeilen, im Browser, die mit einem normalen Zeilenumbruch daherkommen NICHT zusammengefügt werden, das vereinfacht einiges... weil ich auch hier keinen Grund sehe "dagegen" zu optimieren. Also kann man dann auch ein harten Zeilenumbruch setzen, oder es ganz lassen. Aktuell jedenfalls. Das mit dem Leerzeichen macht dann auch nicht viel Sinn, der Break kommt im Browser (Firefox) automatisch und daran wird auch nicht gerüttelt. Entscheided der Browser nun, das wir den Text nun doch "zusammenfügen", soll das wohl so sein....

    Habe nun auch die ersten Leerzeichen nach Tags wegfallen lassen, falls vorhanden, damit die Zeilen ordentlich eingerückt sind, macht auch die Ausgabe ein klein wenig kompakter.
    Geändert von theSplit (18.04.17 um 23:10 Uhr)
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  16. #16

    Re: IT-Talents.de Code Competitions

    Im großen und ganzen habe ich mich an das Markdown von John Gruber orientiert.
    Dann mach’s doch komplett anstatt nur »im großen und ganzen«. Weil wenn nicht, ist heimlich still und leise sofort noch ein Markdown-Dialekt entstanden (obligatorisches xkcd). Auch wenn wir hier nur mit Spielbeispielen rumbasteln, kann man den schlechten Angewohnheiten ja gleich vorbeugen. Manche Sachen wegzulassen halte ich für ok, weil ein vollständiger Markdown-Parser ein größerer Batzen Arbeit ist. Aber warum Sachen anders implementieren?

    Jaja, die 2+-Leerzeichen-Regel für harte Zeilenumbrüche. Finde ich auch extremst bescheuert. Aber ist halt Markdown. Sieh’s mal so rum: Dass die Regeln des Formats zu mieser Usability führen, ist doch nicht dein Problem als Parser-Implementierer. Mal davon abgesehen, dass man sich auch im Gruber-Markdown mit einem echten <br> behelfen kann, wenn man wirklich einen sicheren, harten Zeilenumbruch braucht. HTML ist ja überall erlaubt.

    und was genau stellst du dir darunter vor, welche "Sonderfälle", sowas wie genestete Listen und andere Elemente die nicht in der Aufgabe stehen?
    Ich hatte v.a. die Spezialfälle in meinem Testdokument im Auge. Die könnte man zum Großteil sogar noch als Teil der Aufgabe interpretieren. Implizit ausgeschlossen sind ja eigentlich nur geschachtelte Listen.


    In meinem Bastelkeller fängt die Sache auch an, Formen anzunehmen. Absätze und Listen gehen, Listenpunkte mit mehreren Absätzen schaut auch gut aus, genauso weiche Zeilenumbrüche. Wahrscheinlich. Es gibt noch keine Ausgabe, aber die Testfälle sind grün.

    Was ich bisher gelernt habe: Grammatik schreiben ist hart! Weil’s eine ganz andere, ungewohnte Art zu denken braucht. Grammatiken sind zum Großteil deklarativ. Mein objektorientiert/prozedural geprägtes Hirn will den Scheiß ständig hinschmeißen und es auf gewohnte Art runterprogrammieren. Deswegen will mir auch die Frage nicht aus dem Kopf gehen, ob ein Parserframework wie Spirit für ein Format vom Kaliber Markdown wirklich das richtige Tool ist. Ob da was dran ist oder mir nur das ungemütliche, weil ungewohnte, Denkmodell ein Vorurteil reindrückt, da bin ich mir nicht sicher.

    Über kontextfreie vs. kontextsensitive Grammatiken mach ich mir auch so meine Gedanken. Haben will man eigentlich ersteres, weils schön einfach und eindeutig ist. Markdown ist zweiteres, aber wie! Es gibt mindestens zwei Arten von Kontext. Markdown nimmt die natürlich beide mit.

    Die einfach Art von Kontext: Wenn ich Token X parse und als semantisches Element E interpretiere, aber nur, wenn danach (oder davor, ist das gleiche in grün) Token Y folgt, ist das nicht mehr frei von Kontext. Ich muss einen Lookahead machen – also in den Kontext namens »Zukunft« schauen – um meinen aktuellen Zustand eindeutig interpretieren zu können. Markdown-Beispiel:
    Code (C++):
    1. const auto paragraph_separator =
    2.       eoi                 // end-of-input; oder
    3.     | (eol >> +eol)       // end-of-line gefolgt von 1-n eol
    4.                           // also effektiv 1-n Leerzeilen; oder
    5.     | (eol >> &lit("* "); // einzelnes eol, falls danach ein "* "
    6.                           // (ein Listenstart) kommt
    Der letzte Fall ist der kontextabhängige. Warum klappt ein simples Zeilenende gefolgt von einem "* " nicht? Weil ich dann das "* " schon als Teil von paragraph_separator geparst habe. Das ist falsch. Und wenn ich weiterparse, stehe ich schon nach dem Listenstart und kann deshalb nicht mehr erkennen, dass hier eine Liste angefangen haben sollte. Auch nicht gerade richtig.

    Das ist aber nur der simple Fall von Kontext. Dann gibt es noch den, der von den Inputdaten abhängt. Sowas hat Markdown auch, z.B. bei Listen mit mehreren Absätzen:
    Code:
    * Punkt 1, Absatz 1
    
      Punkt 1, Absatz 2
    * Punkt 2
    
    Aber:
    
    1. Punkt 1, Absatz 1
    
       Punkt 1, Absatz 2
    2. Punkt 2
    Folgeabsätze desselben Listenpunkts müssen soweit eingerückt werden wie der Listenmarker breit ist: 2 Leerzeichen in der ersten Liste (weil Listenmarker »* «), 3 in der zweiten (weil Marker »1. «). Ja, pfui bäh! Jetzt müsste ich meiner Grammatik also beibringen zu erkennen und zu speichern, wie breit der doofe Marker ist, und das beeinflusst das weitere Parse-Ergebnis. Ob/wie man sowas in Spirit modelliert, weiß ich noch nicht.

  17. #17
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Hi

    Freut mich das die Aufgabe nicht so straight forward ist, auch für dich! - Im guten gesprochen, zeigt das die Aufgabe nicht einfach bzw. trival ist.

    Wenn du dich dann noch in eine neue Bibliothek AUCH noch einarbeiten mußt, ist das vielleicht ohnehin noch etwas schwerer, weil einmal die Bibliothek "nutzen lernen und verstehen muss wie die Konzepte sind" und jenes Wissen dann auch erfolgreich auf die Syntax anzuwenden, gemeistert werden muss.

    Ich kann dir soviel verraten, ich habe es auch mit einer, ich nenn es mal "look ahead-detection" für gewisse Sachen gelöst, zu mal ich nur einen einzigen Durchgang der Daten mache und nicht einen analytischen und einen hm, wie nennt man es dann, die Analyse ausführenden Abschnitt teile. Anders könnte ich zum Beispiel nicht unterscheiden, ob Markdown korrekt geschlossen wird und damit "valide" ist.

    Ich habe mir aber auch schon überlegt, ob ich am Ende einer Zeile nicht nur auf den Beginn der nächsten Zeile schauen sollte, sondern auch auf die darauf folgende um dann Elemente zu erkennen die zusammenhängenden würden, also in dem Fall Listen zum Beispiel - die du ja wirklich sehr detailliert ausgeleuchtet hast.

    Allerdings sehe ich eine leere Zeile auch als Trennelement an, will ich Elemente verknüpfen, setze ich keine leeren Zeilen dazwischen, genau auch die Regel nach der zwei Paragraphen getrennt werden.

    Den Widerspruch den du glaube ich "entdeckt" hast, ist mir in ähnlicher Form auch schon beim testen aufgefallen, aber ich weiß jetzt nicht aus dem stehgreif welcher Punkt das genau gewesen ist, es bezog sich glaube auf Zitate und Paragaphen und deren Absätze oder vielleicht doch auf die Zitatidee, Zitate durch leere Zeilen zu trennen, aber auch zu berücksichtigen ob wir nicht ein Zitat mit einem Absatz haben.

    Dieses Markdown von dir zum Beispiel:
    Code (Text):
    1. >Oder umgebrochen:
    2.  
    3. > Auch das ist
    4. > ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!). ### 1
    5.  
    6.  
    7. verus:
    8.  
    9.  
    10. Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.
    11.  
    12. > Ein einzelner Zitatabsatz
    13. mit Umbruch. ### 2 Genau hier hängt meiner Meinung nach der Satz "zusammen", auch wenn kein Whitespace am Zeilenanfang der zweiten Zeile ist, wird aber vom Browser
    14.  
    15. Man kann das natürlich auch kombinieren:
    16.  
    17. > Das mit dem Zitieren
    18. schaut auf Anhieb einfach aus.
    19. > Isses aber nich. Denn dieser ganze Block hier
    20. > ist ein einzelner Zitatabsatz. #3
    #1) Diese Regel hab ich genau umgekehrt behandel, ich und nehme das ">" als Anlass das wir einen neuen Abschnitt haben und forciere einen Umbruch
    #2) GENAU hier entscheide ich mich dafür, das es zusammengehört, weil: Es folgt kein > Zeichen, die Zeilen könnten alles "zusammengefügt werden" auch wenn kein Whitespace am Zeilenanfang da ist, das gibt dem ">" mehr Bedeutung, finde ich - kann aber auch von der Spezification abweichen! - Aber auch der Browser rendert dies anders,
    #3) Die erste Zeile gehört nach meiner "Logik" zusammen, Zeile 3 und 4 haben ein ">", sind also neue Punkte innerhalb eines zusammenhängenden Zitats.


    Was mir aber auch aufgefallen ist:

    Code (Text):
    1. *.................................. <<
    2.   Was ist das denn?
    3. * Na logisch! Ein Listenpunkt mit führender Leerzeile.
    4. * Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?
    5.  
    6. Ein leerer Punkt in einer Liste? Logisch:
    7.  
    8. * eins
    9. *............................. <<
    10. * drei
    << - Hier gibt es kein Leerzeichen das anführt, dennoch meinst du eine Liste liegt vor, dafür müsste allerdings auch ein Leerzeichen darauf folgen, eigentlich wäre dieser Stern also nicht valide um als Listenpunkt zu gelten, wir nehmen es an, "weil wir uns innerhalb einer Liste befinden", oder ist es gar kursive Formatierung die über ein Zeilenende hinaus geht?


    In deinem zwieten Beispiel...

    Code (Text):
    1. * Punkt 1, Absatz 1
    2.  
    3.   Punkt 1, Absatz 2
    4. * Punkt 2
    5.  
    6. Aber:
    7.  
    8. 1. Punkt 1, Absatz 1
    9.  
    10.    Punkt 1, Absatz 2
    11. 2. Punkt 2
    Rein von den Gebrauch von Aufzählungen(!) im Sprachgebrauch:
    Code (Text):
    1. - dies ist ein Punkt
    2. - dieser ist der zweite Punkt und hier machen wir den Satz jetzt mal etwas länger, aber eigentlich fasse ich doch den Sinn von etwas zusammen bzw nenne etwas
    3. - dies ist ein weiteres Merkmal
    4. - Attribute
    5.  
    Im Gegensatz zu so etwas hier:

    Code (Text):
    1. 1. Dokumentation (eine Liste mit zwei Punkten, die erste ebenfalls mit zwei Unterpunkten)
    2.  
    3. __Gute Dokumentation ist wichtig, das haben schon viele andere Programmierer erfahren die sich in etwas einarbeiten wollten, aber keine Dokumentation vorgefunden haben.
    4.  
    5. __Häufig sind wir aber meist recht faul wenn es darum geht, Code zu dokumentieren, da dies nicht zum eigentlichen Wert der Software beiträgt
    6. __Kommentare werden in der Regel nicht bezahlt und sind auch keine Feautres, sie können aber dazu führen das die Wartungkosten gesenkt und Fehler schneller identifiziert werden können.
    7.  
    8.  
    9. __1a. Features?
    10. ____Kommentare?
    11.  
    12. __2b. Einfach?
    13. ____Auch kommentieren will gelernt sein und es ist eine Kunst gute und verständlich für andere zu kommentieren.
    14.  
    15. 2. Eine weitere Überschrift
    16. __Mehr-
    17. __zeiliger
    18. __Text
    19.  
    20. __Absatzt

    Ist ja ein Unterschied. Wobei gut, man kann auch eine Aufzählung ohne "Gedankenstriche" machen und stattdessen Nummerieren. Aber ich habe selten gesehen das "Gedankenstriche" für eine benannte Aufzählung und mit Fließtexten verwendet werden, in denen Absätze vorkommen. Häufiger liegt der Fall meiner Meinung nach bei richtigen "Aufzählungen". Wo man sich auch auf Punkte oder Abschnitte beziehen will.

    Im übrigen zieht sich diese "Theorie" vielleicht auch durch Office Software - Gedankenstriche haben meist einen ein oder mehrzeiligen zusammenhängen Satz und zum Beispiel Open Office lässt dies nicht einmal zu, glaube ich zu wissen.

    Bei Listenelemente sehe ich es allerdings auch so, das man keine Liste nimmt um Aufzählungen zu machen mit Beschreibungen, sondern eher einen Absatz wähl.

    Ich finde aber, man kann, wenn man gute Argumente hat - klassisch nach dem von dir verlinkten Beispiel, auch gegen einen Standard gehen, wenn es gute Gründe dafür gibt - und die Whitespaces am "Ende" sind in vielen Editoren oder Office Dokumenten so gut wie unsichtbar. Daher würde ich NUR und ausschließlich auf die Backslash Regel bestehen und andersherum nur Whitespace am "Zeilenanfang" bzw. nach einem Listenelement akzeptieren.

    Je nach Markdown Element kann Whitespace der Formatierung dienen wie du selbst ja aufzeigst - oder eben auch ein Stilmittel sein bzw. sogar beabsichtigt, von mir aus wie auch ein Tab oder Spaces am Anfang zum Einrücken von Code oder anderen Dingen. Wie gesagt würde ich das an dem Typ festmachen mit dem etwas eingeleitet wird.


    Wenn du magst, kannst du ja auch mal eine HTML Ausgabe posten wenn sie startklar ist, würde mich auch interessieren was sich bei dir entwickelt.


    Zu deiner Idee/Hinweis deine Testcases abzuarbeiten bzw. auszuarbeiten, könnte ich gern versuchen.
    Theoretisch kann man über mehrere Zeilen vorweg parsen bzw. es versuchen, sagen wir mal 3 maximal 4 Zeilen und diese beobachten wie die sich darlegen, eigentlich sind dabei immer nur die ersten 10 Zeichen, bzw. in verschalteten Listen die "Tiefe", interessant, aber so einfach lässt sich eine Datei ja nicht direkt analysieren.. das man in Zeilen umherspringt meine ich

    Aber man könnte mit solche Analyse Punkten zumindest die Strukturen generell und die von Listen erfassen, aber wenn man die ersten 10 Zeichen beobachtet, natürlich auch noch erfassen ob wir den beginn einer Liste haben oder uns in einer befinden könnten.... aber ich glaube das würde ich jetzt aktuell nicht mehr direkt so umsetzen, dann lieber das Look-Ahead über 3-4 Zeilen vorwärts.

    Und ein Kerngedanke vielleicht noch: theoretisch lebt HTML ja von seiner "Kompaktheit". Das man also nicht fünfzig leere Zeilen zwischen zwei Absätzen oder in Paragraphen oder Zitaten hat, sondern das man höchstens eine, vielleicht maximal 2 leere Zeilen nach einer Überschrift hat. Aber Markdown sehe ich auch als Tool an, um zu Dokumentieren bzw. Texte mit einfachen syntaktischen Elementen zu generieren (auf zweitem Blick), nicht um ein Office Dokument durch HTML zu ersetzen oder Bücher zu schreiben, in der mal 50 Zeilen "weiß" sind oder eine Leerseite dazwischen gemacht wird, damit es schöner aussieht.

    Edit: Achso und wie sagt(e) Knuth - "Premature optimization is the root of all evil!" in diesem Fall kann das auch auf das Zusammenfassen von Elementen bezogen sein oder ähnlichem
    Oder auch, nicht zu "komplex" denken, auch wenn ich letztens mal die Diskussion hatte, dass es genug "DAUs" gibt, die ein System nicht wie "intented" gebrauchen

    Vielleicht lieber mal nen Tag mehr erstellen... und nicht alles durchoptimieren was hinterher vielleicht gar keinen Sinn macht oder nicht so genutzt werden würde, ein paar "Spielregeln" kann man auch vorgeben an die man sich halten muß! Und das ist auch gut so.

    Im schlimmsten Fall macht der Parser dann halt "gar nix".
    Geändert von theSplit (19.04.17 um 20:06 Uhr)
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  18. #18

    Re: IT-Talents.de Code Competitions

    … Es ist unglaublich, wie faul man im Urlaub sein kann … Seeehr angenehm! Aber irgendwann musste es dann doch weiterparsen.

    Straight forward ist Spirit zwar wirklich noch nicht, aber langsam lässt das Gefühl nach, den Parser prozedural selber schreiben zu wollen. Fein. Ich will ja schließlich was lernen bei dem Ganzen. Inzwischen gibt es auch Testcases mit Ausgabe. Dabei ist nebenher der HTML-Generator entstanden. Und zwar wirklich nebenher. Bei solchen Tests ist es am sinnvollsten, erwartete mit tatsächlicher Ausgabe zu vergleichen. Wenns nicht passt hat man nämlich zwei diffbare Texte in der Hand, was beim Fehler suchen ungemein hilft. Eigentlich wollte ich dafür ein simples Plaintextformat erzeugen, aber habe unterwegs gemerkt, dass HTML genau den Anspruch erfüllt. Deswegen besteht im Moment der etwas schräge Zustand, dass der Output-Generator in der Testsuite implementiert ist.

    Falls jemand mit dem aktuellen Stand spielen will: CMake, C++14-Compiler, Boost, doctest. Die Testsuite ist das einzige, das irgendwas tut. Um nur mal in Markdown-Input vs. HTML-Output reinzuschauen, reicht auch ein Blick in die test_parsing.cpp. Alle Testcases machen genau die Gegenüberstellung; und alle sind momentan grün.

    Zitat Zitat von theSplit
    Ich finde aber, man kann, wenn man gute Argumente hat - klassisch nach dem von dir verlinkten Beispiel, auch gegen einen Standard gehen, wenn es gute Gründe dafür gibt
    Ja … nein … kommt drauf an, was du machst. Sprache oder Parser bauen? Wenn du eine eigene Sprache entwirfst, die sich an einen Markdown-Dialekt anlehnt, dann ja, kannst du. Solltest du mit guten Gründen auch. Wenn du einen Parser für einen bestimmten Markdown-Dialekt schreibst, darfst du nicht. Dann ist eine Abweichung vom Standard ein Fehler in der Parserimplementierung, vollkommen egal wie gut begründet.

    << - Hier gibt es kein Leerzeichen das anführt, dennoch meinst du eine Liste liegt vor, dafür müsste allerdings auch ein Leerzeichen darauf folgen
    Das ist offenbar dialektabhängig. Die CommonMark-Spec, Example 239 und 240 sagt, es ist kein Leerzeichen nach dem Listenpunkt nötig, bzw. die Anzahl der Leerzeichen spielt keine Rolle. Gruber-Markdown verlangt genau das Leerzeichen.

    Zitate sind offenbar auch unterschiedlich. Gruber macht aus dem hier:
    Code:
    > A quote
    with a line break
    > and a different kind of linebreak
    
    > A new quote - maybe ;)
    > that looks a bit cleaner.
    >
    > Oh, and it has a second paragraph.
    das da:
    Code:
    <blockquote>
      <p>A quote
    with a line break
    and a different kind of linebreak</p>
    
    <p>A new quote - maybe ;)
    that looks a bit cleaner.</p>
    
    <p>Oh, and it has a second paragraph.</p>
    </blockquote>
    In CommonMark sind das zwei Zitate, getrennt durch die erste Leerzeile.

  19. #19
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Wie kommst du voran @Brother John? Genießt du das Wochenende oder schuftest du schwer bzw. gehört das Schuften zum genießen oder auch (schon wieder) zum Wettbewerb?

    Ich habe heute mal die erwähnten Quotes in Angriff genommen die du hier schilderst, so wird der Inhalt noch zusätzlich in einen Paragraphen eingebunden.

    Das einzige Problem das ich so nicht lösen konnte bisher:

    Leere Zitatzeichen, weil der Parser nun nicht weiß ob wir nur ein Zitat haben, oder ob wir nur ein ">" in einem Paragraphen wrappen sollen weil kein Leerzeichen darauf folgt.
    Ziemlich tricky... jedenfalls für mich...

    Habe mir auch mal die Commonmark Spezifikation angesehen, scheint ja gut dokumentiert zu sein, auch was Sonderfälle angeht.... allerdings, gibt es auch hier wohl noch Probleme:
    https://github.com/jgm/CommonMark/issues/443

    Und genau sowas ist mir beim erarbeiten deiner Testcases auch schon mehr oder minder untergekommen. Irgendwo steht halt ein "if" zu viel oder zu wenig oder der Case wird noch komplexer oder schließt sich aus (oder ich mache es mir zu einfach?).

    Edit:
    Mir ist da aber noch etwas aufgefallen, zur "Preoptimization"

    Folgender Fall:
    Code (Text):
    1. * Leerzeilen
    2.  
    3. * zwischen Listenpunkten
    4. * sind erlaubt
    5.  
    6.  
    7. * auch mehrere Leerzeilen
    Ist das nun eine Liste? - Vielleicht ist hier auch der Fall korrekt, dass es sich um zwei Listen handelt bzw. sogar 3!
    Selbst wenn diese nicht getrennt sind, du nimmst damit vieles "vorweg" wenn du entscheidest, es handele sich um eine lange Liste. Im besten Fall würde ich, für den Angeklagten von zwei Listen bzw. eher noch 3 ausgehen! - Eine Liste hängt "zusammen". Auch hier sollte das gleiche System wie für Paragraphen beibehalten werden.

    Auch machtein normaler Zeilenumbruch im Fluss des Browsers bei einer Liste keinen direkten Unterschied bei der Darstellung, außer man setzt einen harten Break dazwischen.


    Edit2:

    Hier noch etwas zum Testen:

    Code (Text):
    1. > A quote
    2. with a line break
    3. > and a different kind of linebreak
    4.  
    5. > A new quote - maybe ;)
    6. > that looks a bit cleaner.
    7. >
    8. > Oh, and it has a second paragraph.
    9.  
    10. a empty quote:
    11.  
    12. >
    13.  
    14. which becomes completely ignored...
    15.  
    16. Or what is that here:
    17.  
    18. *
    19. *
    20.  
    21. Two stars, wrapped into one paragraph? No, its a list of two empty elements.
    22.  
    23.  
    24. In comparison to
    25.  
    26. *
    27.  
    28. *
    29.  
    30.  *
    31.  
    32. The last one is not at the start of the line.
    33.  
    34. With a preceeding whitespace
    35.  
    36. > A soft line break
    37.  if we have a preceeding space in front of a line
    38.  
    39. > Versus this
    40. > here, those are two totally indenpented lines
    41. > and here is the hard line break too, cause we are citing and FORCE a wrap
    42.  
    43. But also:
    44.  
    45. > A new citation
    46. a new line
    47. another line, all ending with soft linebreaks

    ergibt bei mir aktuell:

    Code (HTML5):
    1. <blockquote><p>A quote
    2. with a line break<br/>
    3. and a different kind of linebreak</p></blockquote>
    4.  
    5. <blockquote><p>A new quote - maybe ;)<br/>
    6. that looks a bit cleaner.</p>
    7. <br/>
    8. <p>Oh, and it has a second paragraph.</p></blockquote>
    9.  
    10. <p>a empty quote:</p>
    11.  
    12.  
    13.  
    14. <p>which becomes completely ignored...</p>
    15.  
    16. <p>Or what is that here:</p>
    17.  
    18. <ul><li></li>
    19. <li></li></ul>
    20.  
    21. <p>Two stars, wrapped into one paragraph? No, its a list of two empty elements.</p>
    22.  
    23.  
    24. <p>In comparison to</p>
    25.  
    26. <ul><li></li></ul>
    27.  
    28. <ul><li></li></ul>
    29.  
    30. <p>*</p>
    31.  
    32. <p>The last one is not at the start of the line.</p>
    33.  
    34. <p>With a preceeding whitespace</p>
    35.  
    36. <blockquote><p>A soft line break<br/>
    37.  if we have a preceeding space in front of a line</p></blockquote>
    38.  
    39. <blockquote><p>Versus this<br/>
    40. here, those are two totally indenpented lines<br/>
    41. and here is the hard line break too, cause we are citing and FORCE a wrap</p></blockquote>
    42.  
    43. <p>But also:</p>
    44.  
    45. <blockquote><p>A new citation <!-- hier könnte man theoretisch auch einen <br/> setzen, weil das nächste Zeichen kein Leerzeichen ist und der satz "verschmelzen" könnte. -->
    46. a new line  
    47. another line, all ending with soft linebreaks</p></blockquote>
    Geändert von theSplit (23.04.17 um 14:41 Uhr)
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  20. #20

    Re: IT-Talents.de Code Competitions

    Hallo miteinander,
    ich werde ebenfalls teilnehmen und nutze ausschließlich "Vanilla" JS.

    Hier mal aktuelle Parsing-Ergebnisse

    markdown:
    Code (HTML):
    1.  
    2. # markdown to html
    3. ## by *Kevin Sieger*
    4.  
    5. Dieser effiziente markdown-Parser, welcher **fetten**
    6. sowie *kurisven* Text unterstützt ist komplett in JavaScript
    7. geschrieben und benötigt keine API oder Frameworks.
    8.  
    9. * Außerdem werden
    10. * unnummerierte Aufzählungen
    11. * unterstützt
    12.  
    13. >Blockquotes funktionieren sowohl
    14. >in der Ausführlichen Variante mit einem '>'
    15. >in jeder Zeile
    16.  
    17. >Als auch in dieser "faulen Variante" mit nur einem Zitat-
    18. Beginn am Anfang
    19.  
    20. Zusätzliche unterstütze markdown-Syntax:
    21.  
    22. 1. Sogar **nummerierte**
    23. 2. Aufzählungen werden richtig umgewandelt
    24. 3. und als *Ordered List* (ol) in HTML ausgegeben
    25.  
    26. 24. Aufzählungen können bei einer beliebigen Zahl
    27. 25. begonnen werden und werden korrekt übernommen
    28.  
    29. [Links](http://www.it-talents.de) werden ebenfalls unterstützt, sowohl im [Fließtext](http://www.it-talents.de "IT-Talents") als auch als ausgeschriebene URL <http://kevinsieger.de>
    30.  
    31. Bilder können ebenfalls eingefügt werden:
    32. ![it-taltens](http://kevinsieger.de/ittalents.png "logo")
    33. **Zum Ausprobieren kann der Text live editiert werden!**
    34.  
    35.  
    HTML:
    Code (HTML):
    1.  
    2. <p>
    3. <h1>markdown to html</h1>
    4. <h2>by <i>Kevin Sieger</i></h2>
    5. </p>
    6.  
    7. <p>
    8. Dieser effiziente markdown-Parser, welcher <b>fetten</b><br/>
    9. sowie <i>kurisven</i> Text unterstützt ist komplett in JavaScript<br/>
    10. geschrieben und benötigt keine API oder Frameworks.</p>
    11.  
    12. <p>
    13. <ul>
    14.     <li>Außerdem werden</li>
    15.     <li>unnummerierte Aufzählungen</li>
    16.     <li>unterstützt</li>
    17. </ul>
    18. <blockquote>Blockquotes funktionieren sowohl in der Ausführlichen Variante mit einem '>' in jeder Zeile<br/>
    19. <blockquote>Als auch in dieser "faulen Variante" mit nur einem Zitat-<br/>
    20. Beginn am Anfang<br/>
    21. </p>
    22.  
    23. <p>
    24. Zusätzliche unterstütze markdown-Syntax:</p>
    25.  
    26. <p>
    27. <ol>
    28.     <li value="1">Sogar <b>nummerierte</b></li>
    29.     <li value="2">Aufzählungen werden richtig umgewandelt</li>
    30.     <li value="3">und als <i>Ordered List</i> (ol) in HTML ausgegeben</li>
    31. </ol>
    32. </p>
    33.  
    34. <p>
    35. <ol>
    36.     <li value="24">Aufzählungen können bei einer beliebigen Zahl</li>
    37.     <li value="25">begonnen werden und werden korrekt übernommen</li>
    38. </ol>
    39. </p>
    40.  
    41. <p>
    42. <a href="http://www.it-talents.de" title="">Links</a> werden ebenfalls unterstützt, sowohl im <a href="http://www.it-talents.de " title="IT-Talents">Fließtext</a> als auch als ausgeschriebene URL <a href="http://kevinsieger.de">http://kevinsieger.de</a> </p>
    43.  
    44. <p>
    45. Bilder können ebenfalls eingefügt werden:<br/>
    46. <img src="http://kevinsieger.de/ittalents.png" alt="it-taltens" title="logo"/><br/>
    47. <b>Zum Ausprobieren kann der Text live editiert werden!</b><br/>
    48.   </p>
    49.  
    Ich nutze hauptsächlich RegExp um zu parsen und benötige so momentan 35 Zeilen Code, wobei das natürlich realtiv gesehen werden muss, da RegExp mir einiges "abnimmt".

    mfg
    Kevin
    Für diesen Beitrag bedankt sich theSplit

  21. #21
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    Hallo Kevin,

    schön dass du auch mitmachst Und hier deine Ergebnisse vorzeigst, sieht soweit alles korrekt aus.

    Wie lange hast du an der Umsetzung, in Javascript, mit den RegEx programmiert bis die gepasst haben? Und 35 Zeilen, nun ja, ich hab knapp ~680 circa... - waren aber auch mal nur "300"...

    Mir fällt aber schon etwas auf:

    Code (HTML5):
    1. <p>
    2. <ul>
    3.     <li>Außerdem werden</li>
    4.     <li>unnummerierte Aufzählungen</li>
    5.     <li>unterstützt</li>
    6. </ul>
    7. <blockquote>Blockquotes funktionieren sowohl in der Ausführlichen Variante mit einem '>' in jeder Zeile<br/>
    8. <blockquote>Als auch in dieser "faulen Variante" mit nur einem Zitat-<br/>
    9. Beginn am Anfang<br/>
    10. </p>
    Einaml, du bindest grundsätzlich alles in einen Paragraphen ein? Außer Überschriften? Warum nicht die Inhalte eines Zitats in ein Paragraphen und warum bei Listen diese in Paragraphen wickeln?
    Zweintens, warum ist hier:

    Code (HTML5):
    1. <blockquote>Blockquotes funktionieren sowohl in der Ausführlichen Variante mit einem '>' in jeder Zeile<br/>
    Das "<br/>" für einen Einzeiler-Text? Das wird gar nicht benötigt. Und vielleicht könnte das Zitat auf gleicher "Ebene" / "Ende" der Zeile auch beendet werden, nicht zwingend darunter. Da es sich nur um eine Zeile handelt bzw. auf gleicher wie das "<blockquote>"-Symbol, damit es "konsistent" wäre.
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  22. #22
    Zeitreisender

    Administrator

    Avatar von drfuture
    Registriert seit
    Jul 2013
    Ort
    in der Zukunft
    Beiträge
    4.398
    ngb:news Artikel
    13

    Re: IT-Talents.de Code Competitions

    @MurmeltierS: Sehr schön - und herzlich wilkommen bei uns
    |_|D *`~{ Ich kenne deine Zukunft }~´* |_|D

  23. #23

    Re: IT-Talents.de Code Competitions

    Zitat Zitat von theSplit Beitrag anzeigen

    Einaml, du bindest grundsätzlich alles in einen Paragraphen ein? Außer Überschriften? Warum nicht die Inhalte eines Zitats in ein Paragraphen und warum bei Listen diese in Paragraphen wickeln?
    Zweintens, warum ist hier:

    Code (HTML5):
    1. <blockquote>Blockquotes funktionieren sowohl in der Ausführlichen Variante mit einem '>' in jeder Zeile<br/>
    Das "<br/>" für einen Einzeiler-Text? Das wird gar nicht benötigt. Und vielleicht könnte das Zitat auf gleicher "Ebene" / "Ende" der Zeile auch beendet werden, nicht zwingend darunter. Da es sich nur um eine Zeile handelt bzw. auf gleicher wie das "<blockquote>"-Symbol, damit es "konsistent" wäre.
    Da scheinen sich wohl noch zwei Fehler eingeschlichen zu haben. Vielen Dank fürs drauf aufmerksam machen!

    Für RegExp war http://regexr.com/ und dessen Cheatsheet mein bester Freund.

    Viel Erfolg euch allen!

  24. #24
    Und der Tag wird gut...

    Veteran

    (Threadstarter)

    Avatar von theSplit
    Registriert seit
    Aug 2014
    Ort
    Da wos weh tut.
    Beiträge
    3.082
    ngb:news Artikel
    1

    Re: IT-Talents.de Code Competitions

    @MurmeltierS: Ich muss gerade schmunzeln, der gute GSkinner.... du hast nicht mal zufällig mit Actionscript programmiert? Da war der Mann sehr weit vorne damals...

    Naja, es sind ja nicht direkt Fehler, du generierst halt evtl. unnötiges HTML - aber wenn du zum Beispiel alles in <p> wickelst, die Paragraphen aber nen "margin-bottom: 40px" haben als CSS-Style, sieht auch das Layout eventuell so aus. Also ich würde auf ein korrektes Einlesen wie auch auf eine "bestmögliche/optimale" Ausgabe Wert legen, daher habe ich das gerade bemängelt

    Es ist ja nicht direkt ein "Fehler".... wie schon gesagt.

    Und dir ebenfalls natürlich viel Glück an dieser Stelle!


    @all: Was ist eigentlich hiermit?

    Code (Text):
    1. Ich bin ein Fließtext, logisch, **aber
    2. das Besondere** an mir, meine Formatierung geht Zeilen übergreifend.
    3.  
    4. * Soll die Formatierung abgebrochen hier übergangen werden?
    5. * Formatieren wir, so viel wie geht? Bzw. bis ein "Textelement" wirklich als beendet gilt?
    Könnte sich auch zu so etwas übersetzen lassen:
    Code (HTML5):
    1. <p>Ich bin ein Fließtext, logisch, <strong>aber
    2. das Besondere</strong> an mir, meine Formatierung geht Zeilen übergreifend.</p>
    Edit: Wie interpretiert denn der Browser sowas?
    Geändert von theSplit (23.04.17 um 19:23 Uhr)
    Gruß theSplit
    --- B.I.E.R. - Born Innocent, Embracing Reason ---
    +++ KISS Ebook Starter [Linux] +++
    +++ Git +++

  25. #25

    Re: IT-Talents.de Code Competitions

    Zitat Zitat von theSplit Beitrag anzeigen
    @MurmeltierS:
    @all: Was ist eigentlich hiermit?

    Code (Text):
    1. Ich bin ein Fließtext, logisch, **aber
    2. das Besondere** an mir, meine Formatierung geht Zeilen übergreifend.
    3.  
    4. * Soll die Formatierung abgebrochen hier übergangen werden?
    5. * Formatieren wir, so viel wie geht? Bzw. bis ein "Textelement" wirklich als beendet gilt?
    Könnte sich auch zu so etwas übersetzen lassen:
    Code (HTML5):
    1. <p>Ich bin ein Fließtext, logisch, <strong>aber
    2. das Besondere</strong> an mir, meine Formatierung geht Zeilen übergreifend.</p>
    Ich unterstütze zumindest Formatierungen fett & kursiv über mehrere Zeilen.

    @all
    Andere Frage:

    Wie behandelt ihr Text der ohne Leerzeile zu einem Block-Element steht.

    Also sowas:

    Code (HTML):
    1.  
    2. Text der nicht von einer Leerzeile von einer Aufzählung getrennt wird
    3. * was passiert damit?
    4. * so stehen lassen
    5. * oder den Text in einen separaten Paragraph verschieben?
    6.  

    Text ohne Paragraph?
    Paragraph nur um Text?

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •