compiler-campusminden / cb-vorlesung-bachelor Goto Github PK

Im Hugo-Re-Learn-Theme 5.x sind die Chapter so organisiert, dass der Titel als H1-Header genutzt wird.

• Baue alle _index.md so um, dass keine H1-Header mehr existieren
• Nutze bei Bedarf neben title auch menuTitle
• Ziehe hidden: true auf die letzte Zeile (davor eine Leerzeile), um es besser sichtbar zu machen
• Die Home-Page (oberstes _index.md) ist nicht hidden
• Orga und Assigments bekommen ein weight: 0

siehe Programmiermethoden-CampusMinden/Prog2-Lecture#592

"index.md" und "_index.md" werden ignoriert, wenn Foliensätze gebaut werden sollen. Durch die Mehrsprachigkeit werden aus den einfachen Index-Dateien welche mit doppelter Endung ("index.ba.md" and "index.ma.md"). Hier klappt das Ignorieren beim Bauen der Folien noch nicht.

SLIDES_SINGLE_MARKDOWN_SOURCES = $(filter-out $(addsuffix %, $(SLIDES_EXCLUDE_DIRS)), $(shell find $(SRC_DIR) -type f -iname '*.md'  ! -iname '*index.md' ! -iname 'tldr.md' ! -iname 'outcomes.md'))

muss angepasst werden ...

Beschreibung des Projekts, Hinweis auf Lizenz

Für die deutschsprachigen Einträge wird nur das erste Word des Titels korrekt im Literaturverzeichnis wiedergegeben, die restlichen Wörter werden alle (teilweise fälschlich) klein geschrieben.

• Bachelor: Abgleich der Themen mit Nelsons Vorlesung
• Master: Abgleich der Themen mit CS 6120 (Cornell), KAIST CS420 und IUCompilerCourse und IUCompilerCourse: Essentials-of-Compilation

Wir haben unsere Organisation "Compilerbau" und das Vorlesungs-Repo "Lecture" genannt. Das passt auch eigentlich ganz gut.

Aber mir ist kürzlich aufgefallen, wenn Studis sich das Repo forken, dass dann der Fork im Studi-Repo auch einfach nur "Lecture" heisst, was nicht besonders aussagekräftig ist.

Mein Vorschlag ist, dass wir den Namen für das Lecture-Repo nochmal überdenken. Vielleicht "CB-Lecture"? Und, damit es keine Doppelungen gibt, den Namen der Organisation anpassen: "Compilerbau @ FHB" (oder so ähnlich, falls das technisch geht).

@bcg7 @AMatutat Was denkt Ihr?

Die aktuelle Veranstaltung soll in zwei neue Module geteilt werden: Ein eher praktisch orientiertes, Front-End-lastiges Wahlfach im Bachelor und ein eher forschungsnahes Modul im Master.

Hierzu muss ein Konzept erstellt werden:

• Wie kann die Transition technisch gemacht werden?
• Wie können wir die zu verschiebenden Teile markieren und darüber diskutieren?
• Welche Teile gehen in den Bachelor, welche bleiben im Master?
• Welche Teile kommen ergänzend neu im Master dazu? Was treibt die Leute aktuell auf den Konferenzen um?

Update: Forken des Repos: 1x neues BA-Repo, 1x neues MA-Repo, 1x temporäres MA-Repo; dieses Repo archivieren
Forken geht aber nur in einen anderen Name-Space und auch nur ohne Umbenennung. Also doch der Weg über git clone, git remote und git push?

(follow-up to https://github.com/Compilerbau/we-can-virtuowl/issues/2)

zusätzlichen PDF-Export anbieten

siehe "org/grading.ma.md"

Die Skizze des AST-Interpreters ist aktuell eine eval()-Methode mit einem switch/case-Konstrukt für den Typ des Knotens und entsprechendem Dispatch auf die Hilfseval-Methoden.

Es wäre gut, hier noch einen Ansatz zu zeigen, wo es überladene eval()-Methoden gibt, wo bereits beim Aufruf mit einem AST-Knoten die richtige Methode durch die Implementierungssprache ausgewählt wird.

Das aktuelle Docker-Image ist für amd64. Um den Container auch auf M1 laufen lassen zu können, sollte das Image als Multi-Arch-Image gebaut werden und zusätzlich arm64 beinhalten.

Vgl. https://docs.docker.com/desktop/multi-arch/ und https://stackoverflow.com/questions/68975743/docker-image-runs-on-intel-mac-but-not-m1-mac

siehe auch Artificial-Intelligence-HSBI-TDU/KI-Vorlesung#101

LLVM ist zweimal drin
VM und Bytecode fehlt ein "V"

aus #16 (comment): ich hab grad noch ne andere (evtl. dumme) idee. im moment baue ich jedes mal im workflow ein neues docker-image und lasse die sachen dann in diesem container laufen. jonas hatte schon mal experimentiert, ob man zeit gewinnen würde, wenn man das image in der gh-registry ablegt und im workflow nur zieht - aber das hat nicht wirklich was gebracht (sagte er damals). wenn man die installationsskripte für die debian-pakete, die man beim erstellen des docker-images ausführt, direkt im ubuntu-runner ausführen würde und danach direkt im ubuntu-runner arbeiten würde, müsste das am ende doch schneller sein, oder? man spart sich das ziehen des basis-images und den overhead des dockerstarts für jeden befehl. was denkst du? lohnt es sich, hierfür nochmal ein ticket aufzumachen und da weiter zu experimentieren? oder ist das nur ne spinnerte idee, die am ende nicht viel bringt? oder sollte man eher nochmal der registry-sache nachgehen (eigentlich müsste das doch deutlich schneller sein als das image neu zu erstellen?!).

gilt für Bachelor wie auch für Master ...

Steps: see Programmiermethoden-CampusMinden/Prog2-Lecture#591

• .gitattributes:

  * text=auto eol=lf
  
  *.cmd text eol=crlf
  *.bat text eol=crlf
  

• .gitignore: für die im Repo tatsächlich betrachteten Dateien formulieren, nicht allgemein für "alles"
• .editorconfig: nochmal überprüfen, ob das alles Sinn macht
• Danach nochmal git add --renormalize . ausführen ...

Bezieht sich auf:

• Compilerbau/CB-Lecture-Bachelor
• Compilerbau/AnnotatedSlides
• Compilerbau/Mini-Python
• Compilerbau/we-can-virtuowl

Siehe https://github.com/Programmiermethoden/PM-Lecture:

• Entferne alle Git Submodule
• Nutze neue GitHub Workflows und die in cagix/pandoc-lecture definierte Docker Action
• Update Konfiguration
• Update Readme/Contrib

In vielen Kursen wird zwischen "konkreter" und "abstrakter" Syntax unterschieden und sogar extra Grammatiken definiert. Damit hat man dann auch eine natürliche Unterscheidung zw. Parse-Tree und AST.

Zumindest sollten wir den Begriff "AST" nochmal präzise(r) definieren.

• Neues public Repo für die Studis anlegen
• Builder-Unterordner per git subtree --push in das neue Repo pushen
• Wiki im neuen Repo ergänzen mit aktualisierter und gekürzter Doku
• Links (Repo, Wiki) in Aufgabenblatt 01 und Orga/FAQ unterbringen (siehe auch #62)

siehe https://github.com/Compiler-CampusMinden/Mini-Python/milestone/1

@CrappyAlgorithm Wie weit ist das Mini-Python-Repo? Kann der Ordner gesplittet werden oder wird es da in den nächsten Tagen noch Änderungen geben?

@CrappyAlgorithm Wie weit ist die Doku, die den Sprachumfang von Mini-Python beschreibt? Kann die schon ins neue Wiki für die Studis?

@CrappyAlgorithm @mpeters4 Wenn ich den git subtree --push mache, dann landet der Inhalt des Builder-Ordners toplevel im neuen Repo. D.h. im Prinzip müsste ich in den Builder-Ordner noch den ganzen Readme/Contrib/License-Kram reintun, damit das "drüben" dann auch sichtbar wird. Andererseits ist das im Mini-Python-Repo dann dupliziert - hier liegt das ja eine Ebene höher nochmal alles rum (und zudem müssten die Links in den Sachen im Builder-Ordner alle auf das Studi-Repo zeigen). Seht ihr hier eine vernünftige Lösung? Wäre das eventuell der Punkt, den Ordner richtig aus dem Mini-Python-Repo zu lösen und nochmal neu als Git-Submodule einzubinden?

Aktuell besteht bei mir das Problem, dass name und email von git im container nicht konfiguriert sind, und sich git daher weigert, die commits zu machen. Die REM-Tags werden allerdings trotzdem gelöscht (wahrscheinlich interessant für dich @liketechnik ). Testweise habe ich im Dockerfile RUN git config --global user.name ... eingefügt, dann funktioniert das Skript. Muss ich da noch irgendwas beachten, damit die Konfiguration in den container übernommen wird?

Originally posted by @malt-r in #16 (comment)

Nach dem Upgrade auf ILIAS 7.x werden im HTML-Lernmodul die Landing-Pages nicht mehr gefunden. Statt foo.de/bar/ muss man nun auf foo.de/bar.html zurückfallen ("ugly URLs).

Leider funktioniert damit dann die neue Print-Funktionalität im Hugo-Relearn-Theme nicht mehr.

Ein Issue ist Upstream eröffnet (McShelby/hugo-theme-relearn#322).

Bis dahin ist die Lösung:

1. Ugly-URLs aktivieren (foo.de/bar/ => foo.de/bar.html)
2. Kanonische URLs aktivieren (foo.de/bar.html => <baseURL>/foo.de/bar.html)
3. Relative URLs deaktivieren (kein Rewriting relativer URLs relativ zum aktuellen Content)
4. Neue Print-Funktionalität wieder entfernen

Aktuell haben wir je ein:

• Lecture-Repo mit
  • Orga-Kram (ändert sich jedes Semester)
  • Vorlesungungsinhalten: Skript+Folien (Markdown), Code-Beispiele (Java, ...)
  • Aufgaben fürs Praktikum (Markdown)
• Vorgabe-Repo mit dem Vorgabe-Code (Java) für die Konzept-Aufgaben
• Musterlösungs-Repo (intern) mit Aufgabe+Vorgabe+Lösung
• Desktop-Repo mit Starter-Code für die Dungeon-Aufgaben
• Musterlösungs-Repo (intern) mit Beispiel-Dungeon
• Quizzes-Repo (intern)
• Semester-Repo mit Git-Subtrees für Vorgabe-Repo und Desktop-Repo, plus Diskussionsforum

Die Aufteilung ist "historisch gewachsen", und am Anfang stand die Idee einer in sich geschlossenen Kurs-Webseite.

• Prüfen, ob die Quizzes ins Lecture-Repo integriert werden könnten und/oder sogar in das Vorlesungsmaterial eingebaut werden können (#332)
• Prüfen, ob die Vorgaben ins Lecture-Repo integriert werden könnten (Vor-/Nachteile? Strukturen?) oder besser in einem eigenen Repo bleiben (dann Aufgaben plus Vorgaben plus Desktop-Dungeon-Starter)
• Prüfen, ob eine andere+einfachere Aufteilung sinnvoll ist:
  • Alternative Struktur A:
    1. Lecture-Repo für Vorlesungsinhalte (Markdown, Slides, Skript/Web, Code-Beispiele, Quizzes) und Aufgaben plus Vorgaben (Markdown, Code-Vorgaben, Desktop als Dungeon-Starter)
    2. Musterlösungs-Repo (intern) für Musterlösung (zieht Lecture-Repo als Git-Submodule/Subtree)
    3. Musterlösungs-Repo (intern) mit Beispiel-Dungeon
    4. Semester-Repo mit Orga, zeitlicher Zuordnung Woche/VL/Aufgaben/Abgaben/... und Links in die Webseite/ILIAS, Diskussionsforum
  • Alternative Struktur B:
    1. Lecture-Repo für Vorlesungsinhalte (Markdown, Slides, Skript/Web, Code-Beispiele, Quizzes)
    2. Repo für Aufgaben und Vorgaben (Markdown, Code-Vorgaben, Desktop als Dungeon-Starter)
    3. Musterlösungs-Repo (intern) für Musterlösung (zieht Aufgaben-Repo als Git-Submodule/Subtree)
    4. Musterlösungs-Repo (intern) mit Beispiel-Dungeon
    5. Semester-Repo mit Orga, zeitlicher Zuordnung Woche/VL/Aufgaben/Abgaben/... und Links in die Webseite/ILIAS, Diskussionsforum

Im Lecture-Repo würden dann nur noch echte Inhalte gesammelt, d.h. bei den Übungsblättern nur noch die Aufgaben-Fragmente. Die Inhalte des Lecture-Repo (Slides, Skript, evtl. Aufgaben) würden dabei als PDF und/oder als Webseite gerendert/bereitgestellt.

In einem Semester-Repo würde das dann konkret für das jeweilige Semester zugeordnet. d.h. dort hat man dann einen Table mit Woche, VL-Themen (Link auf die gerenderten Inhalte), Links auf Aufgaben(-fragmente) (Markdown), Abgabedaten, Abgabemodus, ... das ist eigentlich nix, was ins Lecture-Repo gehört (hier sollten nur inhaltliche Dinge rein). Das Semester-Repo (und ggf. das Aufgaben-Repo) werden als reine Markdown-Inhalte mit Preview in der GitHub-Oberfläche bereitgestellt. Das Semester-Repo wird nach jedem Semester archiviert und ggf. als Template für das Folgesemester benutzt (und danach gelöscht).

Pandoc: 2.19.0
Hugo: 0.101.0

siehe Programmiermethoden-CampusMinden/Prog2-Lecture#590

Bibtex: add langid = {en} or langid = {de} to ensure proper case

siehe #128: Das Tooling hat Schwierigkeiten mit lokalen Images.

Repo doch aufteilen in BA und MA?

• (-) initialer Aufwand
• (-) einige Inhalte und Abbildungen sind doppelt
• (+) die Vorlesungen werden aber ohnehin stärker auseinander driften - eigene Strukturen erscheinen lohnenswert
• (+) Lesbarkeit erhöht sich (kein Anhängsel mehr)
• (+) Issue-Tracker ist Zielgruppen-spezifisch

Abstimmung mit @liketechnik, @CrappyAlgorithm und @mpeters4

We CAN VirtuOWL/Alberta verlinken: Readme ("Credits"), _index.md ("Kooperation mit University of Alberta")

https://www.uni-bielefeld.de/uni/profil/international/netzwerke/alberta-owl/we-can-virtuowl/
https://www.fh-bielefeld.de/presse/pressemitteilungen/internationale-digitale-lehre-eroeffnet-neue-perspektiven

https://www.fh-bielefeld.de/internationales/presse/we-can-virtuowl-persoenliche-begegnung-in-kanada
https://www.fh-bielefeld.de/en/international-office/alberta-owl-cooperation

• Siehe <!-- TODO --> in den Aufgabenblättern
• Projektideen BA:
  • OOP-Erweiterungen: Polymorphie (Überschreiben, Überladen, Klassen/Methoden) => zum großen Teil aber schon in der VL ...
  • REPL
  • Syntaxhighlighting, Editor (mit austauschbarer Grammatik)
• Projektideen MA:
  • Interpreter mit JIT und/oder REPL
  • VM und Bytecode
  • Garbage Collection
  • Syntaxhighlighting, Editor (mit austauschbarer Grammatik) => LSP

In CB haben wir viele Abbildungen, die aus LaTeX- oder DOT generiert werden. Das übliche Vorgehen ist, generierte Artefakte nicht einzuchecken und bei Bedarf einfach neu zu bauen.

Das führt in CB zu relativ langen Buildzeiten, sowohl lokal als auch remote (Github-Workflow).

Ideen zur Abhilfe:

• Ignorieren
• Generierte Abbildungen mit ins Repo einchecken
• Lokaler Build: nur make clean benutzen - generierte Abbildungen werden wiederverwendet
• Remote Build: GH-Cache nutzen?

• URL vom offenen ILIAS-Kurs hier im Repo als Start-URL eintragen
• URL vom neuen HTML-Lernmodul als Base-URL in config.yaml eintragen

Helles Logo analog zum aktuellen Logo für den Bachelor-Kurs benötigt

Das prinzipielle Error-Handling in ANTLR wurde demonstriert.

Es wäre schön, noch ein Beispiel für die eigene Fehlerbehandlung zu haben: Error-Listeners und Error-Nodes im Parse-Tree.

Einstieg in die Diskussion:

• https://stackoverflow.com/questions/64627548/antlr-best-practice-for-finding-and-catching-parse-errors
• https://stackoverflow.com/questions/36232361/how-to-walk-the-parse-tree-to-check-for-syntax-errors-in-antlr
• https://stackoverflow.com/questions/64689420/antlr4-errors-not-being-reported-to-custom-lexer-parser-error-listeners

Es wäre gut, wenn es in der Vorlesung (und auf den Übungsblättern und den begleitenden Dokumenten) eine klare Unterscheidung zw. "Expression" (Ausdruck) und "Statement" (Anweisung) geben würde inkl. einer Definition o.ä. ...

Siehe auch https://github.com/Compiler-CampusMinden/Mini-Python/pull/87

• Update Submodule Pandoc-Lecture
• Update Submodule Hugo-Lecture
• Update Submodule Hugo Re-Learn-Theme auf 5.2.1
• Passe YAML an: markdown/**/*.md:
  • type: => archetype: (für alle .md außer den Index-Markdowns)
  • chapter: true => archetype: "home" im obersten _index.md
  • chapter: true => archetype: "chapter" für alle tieferen `_index.md
• config.yaml:
  • Section outputs hinzufügen
  • Zeile disableMathJax: false oberhalb von disableMermaid hinzufügen

siehe auch Programmiermethoden-CampusMinden/Prog2-Lecture#578

Beispiele für Slides

• "Abschlusseigenschaften regulärer Sprachen" und
• "Entscheidbarkeit für reguläre Sprachen"

fehlen noch ...

• README.md:
  • Verweis auf Contributing
  • Verweis auf Credits
  • Lizenzhinweis: Bild, "this work", Authors, Contributers und License (Links)
• CREDITS.md:
  • Inhalte überprüfen/aktualisieren
  • Hinweis auf Authoren, Contributers und Lizenz
• CONTRIBUTING.md: Inhalte überprüfen/aktualisieren
• LICENSE.md: Inhalte überprüfen
• .github/:
  • Keine Vorlagen für Issues
  • Keine Vorlagen für PRs
  • Workflows überprüfen/aktualisieren
• #52

Es gab in 2022 viel Diskussion um Edge-Cases und wie weit die Grammatik bzw. der Parser der Studis reichen soll. Die Frage ist berechtigt - man könnte entweder ganz genau Dinge beschreiben oder sogar mit einer Grammatik vorgeben (was nicht im Sinne der Aufgabe wäre!) oder über Testfälle gehen (was auch umständlich ist).

Letztlich sollten die Expressions "funktionieren": Binäre und unäre Expressions sowie die üblichen Vorrangregeln. Letztere könnte man ggf. noch verlinken ....

Abstimmung mit @liketechnik, @CrappyAlgorithm und @mpeters4

Das aktuelle Tooling (vgl. cagix/pandoc-lecture#28) kennt "Images" (leerer Titel) und "Figures" (nicht-leerer Titel).

Images werden über das Relearn Theme als Abbildung mit Lightbox gerendert, dazu konvertiert ein Lua-Filter die Skalierung von Pandoc-Markdown in das Format vom Relearn Theme. Das funktioniert sowohl mit lokalen Abbildungen als auch URLs.

Figures werden vom Lua-Filter in einen customized img-Shortcode übersetzt, der etwas Pfadmagie betreibt und dann eine HTML-figure-Umgebung erzeugt.

Bei unserer Konfiguration (Multi-Lang, Ugly URL, Singe-File-Pages) klappt das mit lokalen Images nicht so richtig: Die Bilder werden von Hugo nur im Ordner der Defaultsprache abgelegt, d.h. die Referenzen in den anderen Sprachen müssen entsprechend dorthin umgebogen werden. Bei Web-Images (mit URL) ist das kein Problem, bei Figures rechnet unser img-Shortcode den Pfad um. Nur bei "normalen" Images klappt die Auflösung nicht (die müsste durch das Hugo Relearn Theme erledigt werden) - und die Nicht-Defaultsprache ist dann quasi kaputt.

Ideen zur Lösung:

• Images immer als Web-Images einbinden - URL in unserer Repo
  • sehr umständlich und schlecht zu lesen
  • klappt das mit LaTeX?
• Images auch als img-Shortcode ausgeben
  • das macht die Image-Links für "normale" (einfachsprachige) Vorlesungen kaputt
• Repo doch aufteilen in BA und MA
  • initialer Aufwand
  • einige Inhalte und Abbildungen sind doppelt
  • die Vorlesungen werden aber ohnehin stärker auseinander driften - eigene Strukturen erscheinen lohnenswert
  • Lesbarkeit erhöht sich (kein Anhängsel mehr)
  • Issue-Tracker ist Zielgruppen-spezifisch

• Einträge noch einmal überprüfen
• Abgabehinweis unter Stundenplan notwendig?

Describe the bug
The delete-rem-tags script cannot be executed.

To Reproduce
Steps to reproduce the behavior:

1. Add a <!-- REM --> pair to one of the markdown files (e. g. https://github.com/Compilerbau/CB-Lecture-Bachelor/pull/11/files)
2. Build the docker image in .github/actions/alpine-pandoc-hugo/: cd .github/actions/alpine-pandoc-hugo/ && make
3. Execute make delete-rem-tags
4. Observe the following output message (abbreviated): git-error: "fatal: unsafe repository ('/data' is owned by someone else)"

Expected behavior

The script runs and adds the commits according to the rem tags.

Desktop (please complete the following information):

• OS: Linux
• Browser not relevant
• Version not relevant

Additional context

• You may need to rebuild the docker image from scratch in order to get the latest git version inside the image.

• Does not occur when executing the docker image as non-root user with podman

• Originally reported by @malt-r (I hope you are able to edit this issue's description, feel free to change anything I misreported here).

Dazu muss die Datei markdown/frontend/parsing/lr-parser.ma.md kopiert und passend umbenannt werden. Beide Dateien müssen dann unter data/ma/schedule.yaml eingetragen/verlinkt werden.

Danach können die Inhalte auseinander gezogen werden, so dass es für eine Intro-Vorlesung und einen fortgeschritteneren Teil reicht.

vgl. https://www.fh-bielefeld.de/elearning/goto.php?target=fold_670035&client_id=FH-Bielefeld

Im Intermediate/Intro Teil der Vorlesung wird aus der Datei pandoc.dot ein Bild generiert, das hinterher gar nicht benutzt wird. Außerdem sind die folgenden Nodes in dem Bild zu klein für die Labels:

https://github.com/Compilerbau/Lecture/blob/78a1264bf15463b5c846d2e00ac1367ba3aba90e/markdown/intermediate/intro/images/pandoc.dot#L31

https://github.com/Compilerbau/Lecture/blob/78a1264bf15463b5c846d2e00ac1367ba3aba90e/markdown/intermediate/intro/images/pandoc.dot#L39

https://github.com/Compilerbau/Lecture/blob/78a1264bf15463b5c846d2e00ac1367ba3aba90e/markdown/intermediate/intro/images/pandoc.dot#L43

Die Erkennung von Mathe ist furchtbar in Hugo ... Außerdem zieht Hugo und/oder das verwendete Template diverse Bibliotheken (Problem wg. der Datenschutzerklärung). Zusätzlich braucht die Kombination von Pandoc und Hugo zu lange zum Übersetzen der Seiten.

Kann man die Webseite in pure-Pandoc nachbauen?

• Pages mit eigenem Template
• Navigation in Page mit TOC
• Navigation über alle Pages mit Menü
• Konfigurierbarer Schedule

siehe auch cagix/pandoc-lecture#10