Kiste
DE

The book is currently only available in German.

Programm verschicken — die `.exe`-Datei

Verfügbar in der Kiste IDE — implementiert in Phase 9.5 (F7-Build-Action, 2026-05-17) und Phase 9.5.1 (frage() im LLVM-Pfad, 2026-05-17).

Bisher hast du deine Kiste-Programme in der IDE laufen lassen — F5 drücken, Output im Panel anschauen, fertig. Aber irgendwann willst du ein Programm verschicken: einer Freundin auf den Stick kopieren, in einen Download-Ordner stellen, ein kleines Tool für die Buchhaltung an einen Kollegen weitergeben.

Dafür brauchst du eine .exe-Datei — eine eigenständige Datei die ohne installierte Kiste läuft. Die Kiste IDE baut die mit einem Tastendruck.

Ohne IDE — direkt im Terminal: du brauchst die IDE nicht, um zu bauen. Das geht auch auf der Kommandozeile:

kiste build mein_programm.ki -o mein_programm.exe   # baut die .exe
kiste build mein_programm.ki -o mein_programm.exe -release   # optimiert (kleiner/schneller)

Genau dasselbe macht die IDE-Aktion unter der Haube.

33.1 Die Build-Aktion (F7)

Drei Wege das Gleiche zu tun:

  • Taste F7 — schnellster Weg.
  • Blauer Knopf im linken Seitenstreifen (unter dem grünen Run-Knopf) — wenn du lieber klickst.
  • Befehlspalette Ctrl+Shift+P → „Build (.exe in dist/)" — für die, die suchen statt sich merken.

Alle drei machen das Gleiche: deine aktuell geöffnete .ki-Datei wird zu einer .exe kompiliert und in einen dist/-Ordner neben deiner Quelldatei gelegt.

Beispiel: du arbeitest an C:\Projekte\rechner.ki. Nach F7 hast du C:\Projekte\dist\rechner.exe — fertig zum Verschicken.

Voraussetzung: die Datei muss gespeichert sein (Ctrl+S). Eine dirty Datei (mit dem ●-Marker in der Tab-Leiste) lehnt F7 ab — die Statusleiste sagt dir warum.

33.2 „Im Ordner anzeigen"

Nach erfolgreichem Build erscheint ein kleines Dialog-Fenster mit dem vollständigen Pfad zur .exe. Zwei Knöpfe:

  • Im Ordner anzeigen — öffnet den Windows-Explorer mit der Datei pre-selektiert. Praktisch zum schnellen Verschicken via Rechtsklick → „Senden an …".
  • Schließen — Dialog weg, weiterarbeiten.

Der Dialog schließt sich nicht automatisch — du entscheidest wann. Esc-Taste oder Klick außerhalb des Dialogs tun's auch.

33.3 Fenster offen halten mit frage()

Hier ist eine Stolperfalle die du sofort sehen wirst: doppelklick auf eine frische .exe, ein Konsolen-Fenster blitzt auf — und ist sofort wieder weg.

Das ist normal. Windows öffnet die Konsole, dein Programm druckt seinen sag-Output, Programm endet, Konsole schließt. Bei jedem Konsolen-Programm so (Python, Go, Rust, alle).

Damit der User das Ergebnis lesen kann, bittest du am Ende um einen Tastendruck — mit frage():

sag "Hallo Sascha!"
sag "fib(30) ="
sag fib(30)

nimm x = frage("Drücke Enter zum Beenden: ")

Was passiert:

  1. Programm druckt alles.
  2. frage("Drücke Enter zum Beenden: ") druckt den Prompt und wartet auf eine Eingabe.
  3. User drückt Enter (oder tippt was, ist egal — x wird einfach nicht benutzt).
  4. Programm endet, Fenster schließt.

frage() ohne Prompt geht auch: frage() wartet einfach auf Enter ohne was zu drucken. Aber ein Prompt macht's für den Endnutzer klarer.

33.4 dist/ in .gitignore

Wenn du dein Projekt in Git verwaltest, gehört dist/ in die .gitignore — die gebauten .exe-Dateien sind Build-Artefakte, kein Source-Code:

# .gitignore
dist/

Das ist die gleiche Konvention wie bei Rust (target/) oder Java (build/). Wenn du Git neu bist: Git ist ein Versions-Verwaltungs-Tool — wir behandeln das später, du musst es heute nicht können.

33.5 F5 vs. F7 — wann was?

Aktion Wann Was
F5 — Run Testen während der Entwicklung — schnelles iteratives Probieren. Baut die .exe in einen temporären Ordner und führt sie sofort aus. Output ins IDE-Panel.
F7 — Build Verschicken — .exe für andere User produzieren. Baut die .exe in <projekt>/dist/<name>.exe. Führt sie NICHT aus.

Faustregel: solange du tippst und testest, F5. Wenn du das Programm an jemanden weitergeben willst, F7.

33.6 Wenn der Build fehlschlägt

Wenn dein Programm Sprach-Features nutzt die im LLVM-Native-Pfad noch nicht verfügbar sind (z.B. das geld-Modul oder Higher-Order-Funktionen aus liste), siehst du:

=== Native Build (kiste build) ===
fehler.ki:5:12  noch nicht im Phase-9.1-Subset: ...
=== Build fehlgeschlagen (87ms) ===

Status-Bar zeigt ✗ Build fehlgeschlagen. Kein Modal. Die Diagnose im Output-Panel sagt dir was nicht geht und meist auch wie du es umschreibst.

Wichtig: der Tree-Walker-Pfad (kiste run im Terminal) versteht die volle Sprache — wenn dein Programm out-of-subset ist und du keinen Workaround brauchst, läuft es dort weiterhin. Aber eine .exe ist heute auf das Native-Subset begrenzt. Die Lücke schrumpft mit jeder Phase.

33.7 Schnell bleiben — was im Build heute Zeit kostet

Reines Rechnen ist in der .exe pfeilschnell (Millionen Operationen pro Millisekunde). Und seit 2026-06-12 sind auch die häufigsten Daten-Zugriffe nativ: liste[i] (lesen UND schreiben — l[i] = x samt l[i] += x), bytes.byte_bei(...), länge(liste/bytes) und wiederhole-Schleifen kosten nur noch Nanosekunden (vorher je ein Brücken-Aufruf à ~3 µs — die Taktgeber-Analyse fiel damit von 4,1 s auf 1,1 s). nimm im Schleifenkörper ist ebenfalls gratis (Bug 006, gefixt).

Was heute noch über die interne Brücke geht und in heißen Schleifen Mikrosekunden kostet:

  1. Modul-Globals — einmal in eine lokale Variable ziehen, wenn eine Funktion sie in einer heißen Schleife braucht: nimm daten = mein_global vor der Schleife, dann nur noch mit daten arbeiten.

  2. wert.als_ganz/als_komma auf liste<beliebig>-Elementen — bei Zahlen-Listen lohnt eine typreine Liste, dann entfällt das Auspacken ganz. Der Weg dahin (seit 2026-06-12): liste.gefüllt(n, startwert) baut eine große typreine Liste in einem Schlag — liste.gefüllt(1024, 0.0f) ist ein nativer komma-Puffer, auf dem l[i]-Lesen UND -Schreiben Nanosekunden kosten. (Achtung: Listen, die per liste.hänge_an WACHSEN, werden intern zu liste<beliebig> — feste Puffergröße + gefüllt ist der schnelle Weg.)

  3. karte[k]-Zugriffe und Text-Operationen — pro Zugriff ein Brücken-Aufruf; in heißen Schleifen sparsam einsetzen.

Ein vollständiges Beispiel, das diese Rezepte anwendet (und misst!), ist beispiele/taktgeber/taktgeber.ki — dort läuft seit 2026-06-12 sogar eine eigene Radix-2-FFT komplett in Kiste (Spectral-Flux-Schlagerkennung): typisierte liste.gefüllt-Puffer, native l[i]-Reads und -Stores, ein 192-Sekunden-Lied in ~3,4 s bei voller Abtastrate. Daten-intensive Algorithmen sind im Build damit nicht mehr nur möglich, sondern schnell.