Versuchsdurchführung

Odin (Johannes Frank)

Vorbereitung

Installation Odin

1. Download Neuesten Release herunterladen: https://github.com/odin-lang/Odin/releases 2. Dependencies

sudo apt install clang
sudo apt install lldb

3. Odin zum Path hinzufügen Ersetze /path/to/Odin/folder mit dem tatsächlichen Pfad zum heruntergeladenen Odin-Verzeichnis.

echo 'export PATH="/path/to/Odin/folder:$PATH"' >> ~/.bashrc

Installation des Language Server für Odin (ols)

Als nächstes soll der Language Server ols installiert werden, zur Verwendung mit Editoren wie Helix, Vim, etc.

1. Installation

git clone https://github.com/DanielGavin/ols
cd ols
./build.sh
./odinfmt.sh # To install the odinfmt formatter

2. Ols zum Path hinzufügen Ersetze /path/to/ols/folder mit dem tatsächlichen Pfad zum ols-Verzeichnis.

echo 'export PATH="/path/to/ols/folder:$PATH"' >> ~/.bashrc

Helix unterstützt Odin und Ols standardmäßig, weshalb nun die Einrichtung abgeschlossen sein sollte. Dies kann man in Helix z.B. mit helix --health überprüfen.

Durchführung

Es wurde ein Kommandozeilenprogramm in Odin entwickelt, das Systeminformationen (Betriebssystem, CPU, RAM-Nutzung) zusammen mit einem Debian ASCII-Logo anzeigt. Inspiration dafür ist das deutlich komplexere Tool neofetch. Das Programm soll zentrale Bestandteile von Odin illustrieren:

Modulsystem und Importe: Verwendung von package main und Importen aus der core-Bibliothek (z.B. core:fmt für Ausgabe, core:os für Dateizugriff, core:strings für Textmanipulation, core:strconv für Konvertierungen und core:sys/info für Systemdaten).
Prozeduren und Konstanten: Definition von Prozeduren (z.B. get_ram :: proc() -> (f64, f64)) und Konstanten (z.B. C_BLUE :: "\e[94m" für farbige Ausgabe).
Dateiverarbeitung und String-Manipulation: Die get_ram-Prozedur liest eine Datei (./meminfo als Ersatz für /proc/meminfo) mittels os.read_entire_file_or_err. Der Inhalt wird mit Funktionen aus core:strings (wie split_lines_iterator, split, trim_space) zeilenweise verarbeitet.
Typkonvertierung und Kontrollfluss: Gelesene Textwerte werden mit strconv.parse_int in Zahlen umgewandelt. for-Schleifen, switch-Anweisungen und if-Bedingungen steuern den Ablauf der Datenverarbeitung.
Systeminformationen und formatierte Ausgabe: Informationen zu OS und CPU werden über core:sys/info bezogen. Die finale Ausgabe erfolgt farbig und formatiert auf der Konsole mittels fmt.tprintfund fmt.printf.

Ergebnisse

Bei erfolgreicher Ausführung mit odin run . gibt das Programm die folgenden Informationen auf der Konsole aus:


  _________     OS:         Debian GNU/Linux 12 (bookworm), Linux 6.1.0-37-amd64
 | Debian  |    CPU:        Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
  ---------     RAM:        4217.0 MiB / 15755.2 MiB

Probleme

Debugger-Verknüpfung: Für das Debugging in Editoren wie Helix wird lldb-dap benötigt. Ist dies nicht korrekt verlinkt, kann folgender Befehl helfen (Version ggf. anpassen):

sudo ln -s /usr/bin/lldb-vscode-14 /usr/local/bin/lldb-dap

Lesen von /proc/meminfo: Das direkte Auslesen von /proc/meminfo mit os.read_entire_file_or_err funktioniert in Odin derzeit nicht wie erwartet, da diese speziellen Systemdateien eine Größe von 0 melden, obwohl sie Daten enthalten. Dies führt dazu, dass ein leerer Daten-Slice zurückgegeben wird.
- Das im Beispielprogramm verwendete lokale ./meminfo dient als Workaround, um die Logik zum Parsen der Speicherinformationen zu demonstrieren.
- Ein bekanntes GitHub-Issue zu diesem Verhalten ist: Odin Issue #4264

Web-Assembly (Johannes Knoll)

Vorbereitung

WebAssembly (WASM) ist ein binäres Instruktionsformat, das es ermöglicht, Code in verschiedenen Programmiersprachen zu schreiben. Das Format ermöglicht es Programme mit nahezu nativer Geschwindigkeit im Browser auszuführen.

Es wird typischerweise für performancekritische Anwendungen, wie Spiele im Browser, Bild- und Videobearbeitung, Wissenschaftliche Berechungen oder die Portierung bestehender Desktop-Anwendungen ins Web verwendet.

WebAssembly ergänzt JavaScript für performancekritische Apps, ersetzt es aber nicht. WebAssembly wird typischerweise von JavaScript aus aufgerufen.

Die typische Zusammenarbeit zwischen beiden Technologien sieht so aus:

JavaScript lädt das WASM-Modul
JavaScript ruft WASM-Funktionen für rechenintensive Aufgaben auf
WASM gibt Ergebnisse an JavaScript zurück
JavaScript kümmert sich um DOM-Manipulation und UI

In dieser Demo soll ein kleines WASM-Modul mit dem Web-Assembly-Textformat (kurz WAT) geschrieben werden. Dieses wird dann im Browser von JavaScript geladen und soll eine kleine Funktion ausführen um die Funktionsweise zu demonstrieren.

Um WAT in WASM kompilieren zu können ist das WebAssembly Binary Toolkit notwendig. Unter Arch Linux mit sudo pacman -Syu wabt intallierbar.

Durchführung

WebAssembly verwendet ein stackbasiertes Instruktionsset, bei dem Operationen über einen virtuellen Stack ausgeführt werden. Das macht es einfach implementierbar und kompakt von der Codegröße her.

Eine einfache Berechnung sieht z. B. so aus:

// Berechnung: (5 + 3) * 2
i32.const 5    // Stack: [5]
i32.const 3    // Stack: [5, 3]
i32.add        // Stack: [8]  (nimmt 5+3, legt 8 zurück)
i32.const 2    // Stack: [8, 2]
i32.mul        // Stack: [16] (nimmt 8*2, legt 16 zurück)

Eine einfache WAT-Funktion im Modul das von JavaScript aufrubar ist wird so geschrieben:

(module  ;; Definieren des Moduls
  (func $add (param $a i32) (param $b i32) (result i32)  ;; Anlegen einer Funktion mit Parametern
    local.get $a  ;; Funktionsparameter vom Stack laden
    local.get $b  ;; Funktionsparameter vom Stack laden
    i32.add  ;; Die obersten zwei Stackelemente addieren und zurückgeben
  )

  (export "add" (func $add))  ;; Exportieren der Funktion für JavaScript
)

Diese Funktion kann nun mit wat2wasm module.wat -o module.wasm von WAT in das WASM Binärformat übersetzt (kompiliert) werden. Als Resultat kommt in module.wasm eine Binärdatei raus, die von JavaScript aus eingebunden werden kann und aus der die Funktionen aufgerufen werden.

Das Laden in JavaScript läuft so ab (ohne Fehlerbehandlung):

let wasmInstance = null;

async function loadWasm() {
  // Datei laden
  const wasmResponse = await fetch('module.wasm');
  const wasmBytes = await wasmResponse.arrayBuffer();

  // WASM Modul anlegen
  const wasmModule = await WebAssembly.instantiate(wasmBytes);
  // In globale Variable legen
  wasmInstance = wasmModule.instance;
}

Um nun die WASM-Funktion ausführen zu können, wird folgende JavaScript Funktion benötigt:

function testAdd() {
  // Werte vom Frontend abfagen
  const inputA = document.getElementById('add-a').value
  const inputB = document.getElementById('add-b').value
  // In Integer parsen
  const a = parseInt(inputA);
  const b = parseInt(inputB);
  // WASM Funktion aufrufen
  const result = wasmInstance.exports.add(a, b);
  return result;
}

Ergebnisse

Das WASM-Modul ist in dieser Demo langsamer als JavaScript. Das liegt daran, dass es sich um eine Demo handelt, in der das Beispiel für das Modul möglichst einfach gehalten wird (Addition). Es entsteht für diese einfache Operation zu viel Overhead durch die Kommunikation zwischen JavaScript und WASM, was die Laufzeit erhöht.

WASM glänzt vorallem bei sehr rechenintensiven Aufgaben wie dem Rendern von Grafiken. Es gilt also immer die passende Technologie für jede Aufgabe auszuwählen. In unserem Beispiel hat WASM einen 3x Speedup für das Berechnen der Fibonacci Reihenfolge.

Lua (Sonja)

Vorbereitung

Im Rahmen des Versuchs wurde die Skriptsprache Lua untersucht, mit dem Ziel, grundlegende Sprachkonzepte sowie die Eignung für interaktive Terminalanwendungen zu evaluieren. Lua gilt als leichtgewichtig und effizient und wird häufig in eingebetteten Systemen, Game Engines sowie Konfigurationsdateien eingesetzt.

Installation unter Windows

Da der Versuch unter einem Windows-System durchgeführt wurde, erfolgte die Lua-Installation manuell. Dazu wurde das vorgefertigte Windows-Binary von der offiziellen Quelle heruntergeladen:

Besuch der Website: https://luabinaries.sourceforge.net/download.html
Download der Datei lua-5.4.6_Win64_bin.zip
Entpacken des Archivs nach C:\Program Files\Lua
Um Lua systemweit verfügbar zu machen, wurde der Ordner C:\Program Files\Lua zur Path-Umgebungsvariablen hinzugefügt
Zusätzlich wurde die Datei lua54.exe in lua.exe umbenannt, sodass Lua direkt über den Befehl lua im Terminal gestartet werden kann

Die Installation konnte anschließend durch den Aufruf von lua -v erfolgreich validiert werden.

Durchführung

Zur praktischen Erprobung wurde ein interaktives Lua-Skript erstellt, das die Funktionalität eines einfachen Taschenrechners bereitstellt. Ziel war es, sowohl die grundlegende Syntax als auch die Interaktionsmechanismen (Ein-/Ausgabe, Schleifen, Kontrollstrukturen) zu demonstrieren.

Das Skript implementiert die vier Grundrechenarten (+, -, *, /) und fragt die Benutzerinteraktion zeilenweise über io.read() ab. Die zentrale Kontrollstruktur besteht aus einer while-Schleife mit einem definierten Ausstiegsbefehl (“exit”). Zur Steuerung des Programmflusses wird das Lua-eigene Labeling-System (goto) verwendet, um bei ungültiger Eingabe gezielt zum Schleifenanfang zurückzuspringen.

Ergebnisse

Das entwickelte Skript erwies sich als funktional und demonstrierte die Eignung von Lua für einfache interaktive Aufgaben. Die Umsetzung ermöglichte ein direktes Verständnis zentraler Lua-Elemente wie Funktionen, Kontrollstrukturen, dynamischer Typisierung und Ein-/Ausgabe über die Konsole. Darüber hinaus zeigte sich, dass Lua trotz seiner minimalistischen Syntax eine strukturierte Fehlerbehandlung und nutzerfreundliche Ausgaben realisieren kann.

alt text

Probleme

Während der Installation unter Windows traten zunächst Schwierigkeiten bei der Einbindung von Lua in die Umgebungsvariable Path auf.

Zur Lösung des Problems wurde:

der übergeordnete Ordner (C:\Program Files\Lua) korrekt eingetragen.
die Datei wurde von lua54.exe in lua.exe umbenannt

Nach diesen Anpassungen konnte Lua erfolgreich über lua -v im Terminal aufgerufen werden.

🔐 Passwort-Generator in Ruby (Veit)

📦 Vorbereitung

Im Rahmen des Versuchs wurde die Programmiersprache Ruby erstmals eingesetzt, um die Eignung für einfache, benutzerinteraktive Terminalanwendungen zu evaluieren. Ruby ist bekannt für seine ausdrucksstarke, elegante Syntax und eignet sich besonders gut für Skripte, Automatisierung sowie prototypische Anwendungen. Im Vergleich zu einer statisch typisierten Sprache wie Java fällt auf, dass Ruby deutlich weniger strukturellen Overhead benötigt und viele Aufgaben mit sehr kompakter Syntax gelöst werden können.

Installation unter macOS

<<<<<<< Updated upstream Da der Versuch unter macOS durchgeführt wurde, gestaltete sich die Installation besonders unkompliziert, da Ruby standardmäßig vorinstalliert ist.

▶️ Durchführung

Zur Erprobung grundlegender Sprachelemente wurde ein interaktives Ruby-Skript implementiert, das die Funktionalität eines Passwort-Generators bereitstellt. Ziel war es, ein benutzerdefiniertes Passwort mit optionalem Einsatz von Zahlen, Großbuchstaben und Sonderzeichen zu generieren.

Die Umsetzung diente zugleich dem praktischen Kennenlernen von:

der allgemeinen Syntax von Ruby
dem Umgang mit Arrays, Strings und Methoden
der Steuerung von Benutzereingaben und Verzweigungen

Das Skript wurde vollständig in einer Datei (passgen.rb) umgesetzt und gliederte sich in folgende Hauptbestandteile:

Benutzereingabe: Abfrage der gewünschten Passwortlänge sowie optionaler Zeichentypen über gets.chomp
Zeichensatzdefinition: Aufbau des verfügbaren Zeichenpools abhängig von der Auswahl
Erzeugung des Passworts: Auswahl zufälliger Zeichen per sample und Absicherung, dass jede gewählte Zeichenart mindestens einmal enthalten ist
Ausgabe: Anzeige des generierten Passworts im Terminal

Die Sprache Ruby erwies sich hierbei als angenehm direkt und einsteigerfreundlich. Im Gegensatz zu Java konnte das gesamte Programm mit wenigen Zeilen Code strukturiert und funktionsfähig umgesetzt werden – ohne explizite Klassendefinition, Typisierung oder Compiler.

Das entwickelte Ruby-Skript funktionierte wie erwartet. Es ermöglichte dem Nutzer, interaktiv ein Passwort zu konfigurieren und generieren zu lassen. Die Laufzeit war kurz, die Ausgabe klar strukturiert und der Code auch ohne umfangreiche Kommentierung gut nachvollziehbar.

✅ Ergebnisse

Beispielhafter Terminalablauf:

Wie lang soll das Passwort sein? 12
Zahlen erlauben? (j/n) j
Großbuchstaben erlauben? (j/n) j
Sonderzeichen erlauben? (j/n) j

🔑 Dein Passwort lautet: W9p@x$Lf2#bT

Vorteile:

Kompakte, ausdrucksstarke Syntax
Schneller Einstieg ohne zusätzliche Konfiguration
Keine externen Bibliotheken notwendig
Ideal für Terminal-basierte Tools

⚠️ Probleme

Während der Umsetzung traten folgende Herausforderungen auf:

Mindestlänge vs. aktive Zeichentypen: Bei zu kurzer Eingabe und aktivierten Sonderzeichen konnte das Skript kein gültiges Passwort generieren. → Lösung: Prüfung der Mindestlänge in Abhängigkeit zur Zeichenauswahl
Zufällige Auswahl ohne Typengarantie: Ohne gezielte Absicherung konnten aktivierte Zeichentypen fehlen. → Lösung: Mindestens ein Zeichen pro Typ gezielt einbauen
Eingabevalidierung: Es war möglich, fehlerhafte Eingaben (z. B. Buchstaben statt Zahlen) zu machen. → Verbesserungspotenzial: Ergänzung von Wiederholungsschleifen zur Absicherung