TerminalBasic/openspec/changes/phase-3-runtime-bildschirm/specs/kompat-testkorpus/spec.md at 52ccbb58481d8605a87f1208925c35ab24686d36

Files

Chili Palmer 52ccbb5848 Phase 3 (Kern): Laufzeitbibliothek, Bildschirm und Datei-E/A

Setzt den OpenSpec-Change phase-3-runtime-bildschirm um (77/77 Aufgaben).
Abdeckung laut Inventar: 195 implementiert, 37 offen, 53 Non-Feature.

Vollstaendigkeits-Inventar
- docs/inventar.md mit 285 Eintraegen aus den Themenlisten von
  bas7advr.hlp und qb45advr.hlp, je mit Status und Fundstelle
- crates/tb-frontend/tests/inventar.rs haelt die Tabelle in beide
  Richtungen gegen den Code; der Abdeckungsstand kann nicht veralten

Bruchschritt (Puffer, Host, Korpus)
- Cell/TextScreen ziehen ratatui-frei nach tb-runtime::screen; tb-ui
  behaelt Farbabbildung, Widget und den neuen Terminal-Host
- Host wechselt vom Zeichenstrom auf Anzeige des Zellenpuffers plus
  Ereignisse (Taste, Groessenaenderung, Abbruch)
- Korpusvergleich auf getrimmten Bildschirm-Snapshot; die acht
  bestehenden Sollausgaben blieben dabei unveraendert

Groessenunabhaengigkeit
- 80x25 ist nirgends mehr eine feste Grenze; Groessenaenderungen waehrend
  der Ausfuehrung werden zugestellt (Inhalt oben links erhalten, Cursor
  und VIEW PRINT geklemmt)
- Korpusnachweis: dasselbe Programm bei 80x25 und 120x40 mit je eigener
  Sollausgabe, plus ein Programm mit Groessenwechsel mitten im Lauf

Bibliothek
- Breite Unicode-Zeichen belegen zwei Zellen (Cursor, POS, Randumbruch)
- Bildschirm: CLS, COLOR, LOCATE, WIDTH, VIEW PRINT, SCREEN, CSRLIN, POS
- Tastatur: INKEY$, INPUT$, Funktionstasten-Makros (KEY n / LIST / ON)
- PRINT USING, LPRINT USING, FORMAT$, SetFormatCC
- Mathematik mit kompatiblem PRNG (gleiche Saat, gleiche Folge)
- Datum und Zeit mit Serienwerten ab 1899
- Finanzmathematik: FV#, PV#, Pmt#, IPmt#, PPmt#, NPer#, Rate#, NPV#,
  IRR#, MIRR#, SLN#, SYD#, DDB#
- Datei-E/A: sequenziell, RANDOM (Recordpuffer und UDT-Variablen),
  BINARY, FIELD/LSET/RSET, Statusfunktionen, Dateisystem, MK$/CV
- System: ENVIRON, FRE, CLEAR, TRON/TROFF, STACK, ERDEV, ERR-Anweisung

Altlasten aus Phase 2
- ON ERROR GOTO auf Modulebene ist aus Prozeduren ansprechbar
  (prozeduruebergreifender Fixup im Codegenerator)
- DATA behaelt seinen Rohtext (Gross-/Kleinschreibung, innerer Leerraum)
- Die vier TODO-verify-Zellen der Konvertierungsmatrix sind aufgeloest

Vom Inventar aufgedeckte Fehler
- Zwoelf Non-Features wies der Compiler entgegen der Phase-1-Spec nicht
  ab (CALLS, SSEG, POINT, VIEW, COM, PEN, STRIG, STICK, die
  String*-Routinen, LINE und OPEN "COMn:") -- geschlossen
- Drei Gruppen fehlten im urspruenglichen Umfang: Finanzmathematik,
  Record-Konvertierung, Rest der Dateisystemfunktionen
- bas7advr.hlp allein ist keine vollstaendige Quelle; das Inventar
  bildet die Vereinigung mit qb45advr.hlp

Neue Changes
- phase-3-isam: schliesst Phase 3 ab (Speicherschicht redb)
- phase-3-ortszeit: zieht die UTC-Abweichung zurueck

Neue Abhaengigkeit: unicode-width.
Dokumentiert: sprachreferenz.md und tbvm-design.md sind TODO-frei,
docs/bibliothek.md neu, PLAN.md fortgeschrieben.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-04 06:54:19 +02:00

4.4 KiB

Raw Blame History

ADDED Requirements

Requirement: Korpusabdeckung der Phase-3-Semantik

Der Korpus SHALL um Referenzprogramme mit dokumentierter Sollausgabe für die Bildschirmsteuerung (LOCATE, COLOR, CLS, VIEW PRINT-Scrollen, CSRLIN/POS, Zurücklesen per SCREEN), die Formatierung (PRINT USING inklusive Feldüberlauf), breite Unicode-Zeichen (Doppelzellen, Umbruch am rechten Rand), Datum und Zeit sowie die Datei-E/A in allen drei Zugriffsarten erweitert werden. Dateiprogramme MUST in einem temporären Arbeitsverzeichnis laufen und dürfen keine Artefakte im Projektbaum hinterlassen.

Scenario: Bildschirmsteuerung als Korpustest

WHEN die Testsuite läuft
THEN existiert ein Korpusprogramm, das mit LOCATE und COLOR an definierten Positionen ausgibt, und sein Snapshot entspricht der Sollausgabe

Scenario: Datei-Korpustest hinterlässt nichts

WHEN ein Datei-E/A-Korpusprogramm gelaufen ist
THEN ist das Arbeitsverzeichnis wieder entfernt und der Projektbaum unverändert

Requirement: Nachweis der Größenunabhängigkeit

Die Bildschirmgröße des Test-Hosts SHALL je Korpusprogramm explizit festgelegt und in der Sollausgabe vermerkt sein; ein Vorgabewert MUST NOT stillschweigend gelten. Mindestens ein Korpusprogramm SHALL bei zwei verschiedenen Bildschirmgrößen laufen und je Größe eine eigene Sollausgabe besitzen, um nachzuweisen, dass Löschen, Umbruch, Scrollen und Cursorgrenzen der jeweiligen Größe folgen. Mindestens ein Korpusprogramm SHALL eine Größenänderung während der Ausführung durchlaufen und danach die neuen Grenzen ausnutzen.

Scenario: Gleiches Programm bei zwei Größen

WHEN dasselbe Bildschirm-Korpusprogramm bei 80×25 und bei 120×40 läuft
THEN stimmt jede Ausgabe mit der Sollausgabe ihrer Größe überein und die Sollausgaben unterscheiden sich in Umbruch- und Scrollverhalten

Scenario: Größenänderung mitten im Programm

WHEN der Test-Host während der Ausführung von 80×25 auf 120×40 wechselt
THEN bleibt der bisherige Inhalt oben links erhalten und die anschließende Ausgabe nutzt die neuen Grenzen

MODIFIED Requirements

Requirement: Korpusdateien mit byte-genauer Sollausgabe

Jedes Korpusprogramm tests/compat/<name>.bas SHALL eine <name>.out mit dem exakten Sollzustand des Bildschirms besitzen (UTF-8, LF-Zeilenenden). Die Sollausgabe SHALL den Zellenpuffer als Textbild abbilden, getrimmt bis zur letzten belegten Zeile und Spalte; nachgestellte Leerzeichen innerhalb einer Zeile sind signifikant — PRINT gibt Zahlen mit führendem Vorzeichen-/Leerzeichen und nachgestelltem Leerzeichen aus. Verwendet ein Programm COLOR, SHALL die Sollausgabe zusätzlich eine Attributebene gleicher Abmessung enthalten; ohne COLOR MUST sie entfallen. .gitattributes MUST die .out-Dateien vor Zeilenenden-Konvertierung schützen.

Scenario: Zahlformatierung in der Sollausgabe

WHEN ein Korpusprogramm PRINT 1; 2; 3 enthält
THEN lautet die Sollzeile 1 2 3 (mit nachgestelltem Leerzeichen)

Scenario: Getrimmter Snapshot

WHEN ein Korpusprogramm nur zwei Zeilen ausgibt
THEN umfasst die Sollausgabe genau diese zwei Zeilen und keine leeren Folgezeilen

Scenario: Attributebene nur bei COLOR

WHEN ein Korpusprogramm ohne COLOR läuft
THEN enthält seine .out keine Attributebene

Requirement: Laufzeitvergleich über den Korpus

Ein automatischer Test SHALL jede Korpusdatei tests/compat/*.bas kompilieren, über die VM mit einem Host ohne Terminal ausführen und den resultierenden Bildschirmzustand gegen die zugehörige .out-Datei vergleichen — getrimmt, mit signifikanten Leerzeichen innerhalb der Zeilen und, sofern vorhanden, einschließlich der Attributebene. Bei Abweichung MUST der Test Datei, erste abweichende Zeile sowie Soll und Ist nennen; weicht nur die Attributebene ab, MUST er Zeile, Spalte, Soll- und Ist-Attribut nennen.

Scenario: Korpus läuft mit korrekter Ausgabe

WHEN die Laufzeit-Testsuite läuft
THEN stimmt der Bildschirmzustand jeder Korpusdatei mit ihrer .out überein

Scenario: Abweichung wird benannt

WHEN ein Korpusprogramm eine abweichende Ausgabe erzeugt
THEN schlägt der Test fehl und nennt Datei, Zeilennummer, Soll- und Ist-Zeile

Scenario: Abweichendes Farbattribut

WHEN ein Korpusprogramm dasselbe Textbild, aber ein abweichendes Attribut erzeugt
THEN schlägt der Test fehl und nennt Zeile, Spalte, Soll- und Ist-Attribut

4.4 KiB Raw Blame History Unescape Escape