6ec85905d4542d68a0a29029eab9cad7708ae3e4
15 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 m.stangl
|
40e8331695 |
[TEST] Referenz-Namenskonvention vereinheitlicht + Kreisel/Omniflo-Referenzen abgenommen
Konvention: Eine Referenz traegt IMMER denselben Dateinamen wie das Ist- Ergebnis in output/ (nur anderes Verzeichnis). Referenz festlegen = Datei aus output/ unter gleichem Namen nach reference/ kopieren. - tests/README.md: neuer Abschnitt "Referenz-Namenskonvention (vereinheitlicht)" mit Regel/Tabelle/copy-Beispiel; Namenskonventions-Tabelle, Fixture-Vorlage (<modul>_tests.dxf statt <modul>_ref.dxf) und die Workflow-Referenzabschnitte angeglichen. - tests/conftest.py: kreisel_ref_dxf laedt reference/kreisel_tests.dxf (vorher kreisel_ref.dxf). - tests/test_omniflo.py: Referenz reference/omniflo_export.csv (vorher omniflo_export_reference.csv). - Referenzen abgenommen und in Git aufgenommen: reference/kreisel_tests.dxf (Umbenennung des Tippfehlers Kresel_ref.dxf), reference/omniflo_export.csv (aus geprueftem output/omniflo_export.csv). Der Batch-Vergleich --diff_references matchte schon immer ueber identische Basisnamen und bleibt unveraendert. Der Kreisel-Referenztest laeuft dadurch jetzt statt zu skippen. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
 s.ayadi
|
e91f1d00d0 |
[REFACTOR] Stufe 2: VF-Eingang/-Ausgang getrennt + Regressionsnetz fuer die Geometrie
Der CAD-Lauf belegt die Schritte 0-4 jetzt auch EMPIRISCH: results/test_hundm05.dxf entstand nach dem Umbau, das Ergebnis-JSON von 11:18 davor - fuer alle 5 Ketten sind ALLE 37 Attribute identisch, inklusive der reihenfolgeabhaengigen Komma-Listen L_VF_m, L_GF_m, GF_WINKEL und ANTRIEBFAHRTRICHTUNG. TEST_VF_SPEC: 28 PASS / 0 FAIL. results/test_linienzug.dxf zeigt eine vollstaendige Kette (AS+ES, Motor, Umlenkung, 2 Vario-Kurven, 22 Bausteine, HOEHE_VON = HOEHE_BIS = 4500 bei DELTA_H 0). Schritt 5a/5b - vfl-vf-eingang-bauen und vfl-vf-ausgang-bauen: beide Bloecke (GF1 + Einlauf-Separator + Umlenkstation bzw. Motorstation + GF2) enthalten keine Frage und sind zusammenhaengend, der Umzug ist wortwoertlich (Zeilenvergleich: 0 Zeilen entfernt, nur zwei Koepfe, zwei Aufrufe und zwei "frame)" neu). Die Auswahl gf2-eff (ziel-gf2 im Kettenende-Modus, sonst L_GF2-bau) bleibt BEWUSST an der Aufrufstelle - genau dort entsteht sonst still die falsche GF2 hinter dem Motor. Der Separator-Zaehler und die vfl-acc-*-Aufrufe bleiben an derselben Stelle in derselben Reihenfolge. Regressionsnetz, damit die restlichen Schritte nicht blind gemacht werden muessen: - lib/dxf_vf_abbild.py (neu): liest eine Testzeichnung streamend und bildet je Kette Attribute, Bausteinzusammensetzung und Einfuegepunkt ab. Ketten werden ueber den EINFUEGEPUNKT der Spec zugeordnet, nicht ueber den Blocknamen - die VF-Nummer beginnt in jeder neuen Zeichnung wieder bei 1. ID und Bezeichnung sind aus dem Vergleich heraus (pro Zeichnung neu). --referenz vergleicht (Exit 1 bei Abweichung), --schreibe-referenz frischt die Referenz nach einem GEPRUEFTEN Lauf auf. - tests/reference/hundm05_attribute.json (neu): die Referenz, erzeugt aus dem geprueften Lauf - also dem Stand, der attributgleich mit dem Zustand VOR dem Umbau ist. - tests/test_vf_geometrie.py (neu, 8 Tests): vergleicht automatisch, mit einem eigenen Test nur fuer die Komma-Listen (das einzige, was eine vertauschte vfl-acc-*-Reihenfolge sichtbar macht) und einer Gegenprobe, dass eine verfaelschte Referenz auch erkannt wird. Das faengt, was der Ergebnis-Record NICHT sieht: er sagt "executed, kein Prompt, Journal aufgegangen", aber nichts darueber, ob dieselbe Geometrie herauskam. Ablauf ab jetzt pro Schritt: umbauen -> TEST_HUNDM05 (save dxf) -> pytest tests/test_vf_geometrie.py. Offen bleiben 5c, 6, 8, 9, 10 (Schleifenrumpf der VF-Einheit, Daten-Executor, Einheit-Abschluss, Kettenebene je Glied, vfl-spec-ausfuehren). Die vier haengen zusammen: 6 und 10 brauchen den aufgeteilten Schleifenrumpf. Halb umgebaut waere der Code schlechter dran als vor oder nach dem Umbau, darum als ein Schritt mit CAD-Lauf davor und danach. Verifiziert: 117 pytest-Tests gruen, vf_linienzug.lsp lint-sauber. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
s.ayadi
|
5902343352 |
[CHANGE] Nur noch EIN Test baut die HundM-Geometrie: Spec wird TEST_HUNDM05
Nach dem gruenen VF_SPEC_BAU-Lauf bauten zwei Tests dieselben 5 Ketten. Der Spec-Pfad ist jetzt der routinemaessige Bau-Test, der Aufzeichnungs-Pfad der abgeschaltete Regressionstest fuer das Journal-Format. Umbenennungen: - tests/testdata/vf_spec_hundm05.json -> tests/testdata/hundm05.json Die Spec ist das Eingabeformat und die Datei, in der weitere Ketten der Anlage nachgetragen werden. spec_ids jetzt VF_hundm05_LZ_* (wie im Aufzeichnungs-Protokoll), damit sich die Ergebnisse beider Laeufe paaren lassen. - tests/testdata/hundm05.json -> tests/testdata/hm_recformat.json tests/test_hundm05.lsp -> tests/test_hm_recformat.lsp (TEST_HM_RECFORMAT, Praefix hmrec:, Export hm_recformat:export-results) tests/test_hundm05.py -> tests/test_hm_recformat.py In alltests.json auf "disabled": true. Neu: tests/test_hundm05.lsp (TEST_HUNDM05) baut die Spec - OHNE eigene Bau-Logik, es ruft vsp-bau-datei aus Lisp/vf_spec.lsp. Damit gibt es genau einen Code-Pfad, der aus einer Spec Geometrie erzeugt; c:VF_SPEC_BAU nutzt denselben. tests/test_hundm05.py prueft das Ergebnis (die 9 Tests, die vorher in test_vf_spec.py standen); test_vf_spec.py ist jetzt reiner Uebersetzer-Test ohne CAD. Warum das Aufzeichnungsformat bleibt (Details in doc/TODO-plan-vf-interactive.md Abschnitt 4.7): - hm_recformat.json ist die EINZIGE eingecheckte Kopie der Originaldaten (data/polylines.dxf ist mit 124 MB per .gitignore ausgeschlossen). Die Spec ist daraus abgeleitet; ohne die Aufzeichnung faellt die rechte Seite des Rundlauf-Beweises weg. - Es prueft eine ANDERE Invariante: das Journal kommt roh aus der XDATA einer Kundenzeichnung. TEST_HM_RECFORMAT ist damit der einzige Test dafuer, dass ein BESTEHENDER VF_n-Block weiter abspielbar ist - also dass Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren. Ein spec-gebautes Journal kann das nicht zeigen, es kommt aus dem Uebersetzer. - Es dokumentiert die Frage-Reihenfolge (kommentar je Eintrag); die Spec verbirgt den Dialog, das ist ihr Zweck. Weitere Anpassungen: - Ergebnisdatei heisst nach der Spec-Datei (<basisname>_results.json), damit Befehl und Testrunner in dieselbe Datei schreiben. Verzeichnis: tests/output (Override DXFM_VF_SPEC_OUT); NICHT DXFM_RESULTS - das sind die Sivas-/ CSV-Exporte, dort landete die Datei ausserhalb des Testbaums. - Neu *vsp-dim-override* fuer TEST_HUNDM05_2D/_3D: wird je Kette angewandt, weil der Abbruch-Handler in vf-linienzug-modus *ssg-ils-dim* zurueck setzt. - Das Anlagenkuerzel der test_id in lib/vf_journal_export.py kam aus dem Namen der Ziel-JSON. Nach der Umbenennung haette eine Regenerierung die ids stillschweigend auf VF_hm_recformat_LZ_* geaendert und die Paarung der beiden Laeufe zerlegt - jetzt feste Konstante TEST_ID_ANLAGE. - conftest: hundm05_* Fixtures -> hmrec_* (die Spec-Fixtures stehen in tests/test_hundm05.py). Verifiziert: 98 pytest-Tests gruen (die 9 Ergebnis-Tests warten auf einen neuen TEST_HUNDM05-Lauf), alle .lsp lint-sauber, Spec-Regenerierung idempotent, TEST_VF_SPEC in BricsCAD 28 PASS / 0 FAIL. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
s.ayadi
|
428f1ced70 |
[FEAT] VF-Linienzug aus Eingabedaten bauen (Stufe 1: Spec -> Journal -> Replay)
Stufe 1 des Fahrplans in doc/TODO-plan-vf-interactive.md, fertig fuer
Modus 1. Eine SPEC beschreibt eine Kette in Domaenenwerten ("links",
"winkel", "aussen", ja/nein) statt in Menue-Codes; vsp-journal uebersetzt sie
in ein Eingabe-Journal, vsp-bau-aus-spec spielt es per
vfl-journal-replay-start durch den UNVERAENDERTEN vf-linienzug-modus. Der
fertige Block traegt damit dasselbe SSG_VF_EDIT-Journal wie eine handgebaute
Kette und bleibt per Doppelklick editier- und 2D/3D-konvertierbar - kein
Journal-Konsument muss etwas von Specs wissen.
CAD-Lauf VF_SPEC_BAU: 5 OK, 0 Fehler. Je Kette status "executed",
prompts 0 (keine Live-Eingabe erreicht), eingaben_offen 0, keine
Spec-Fehler, keine Bau-Meldungen, glieder_ist == glieder_soll,
Einfuegepunkt gleich dem Kettenstart der Spec.
Neu:
- Lisp/vf_spec.lsp: Code-Tabellen, Emitter vsp-journal, Validierung
vsp-pruefen, flacher JSON-Loader, Headless-Rahmen vsp-headless-an/-aus,
Ergebnis-Record, vsp-bau-aus-spec/-liste, c:VF_SPEC_BAU. Von vf_core.lsp
NACH vf_linienzug.lsp geladen - damit sind beide Ladewege abgedeckt (Menue
und der .scr-Loader), das MNL bleibt unveraendert.
- lib/vf_spec_export.py: derselbe Emitter in Python PLUS die Umkehrung
(spec_aus_journal), erzeugt die Spec-Testdaten.
- tests/testdata/vf_spec_hundm05.json: die 5 echten Ketten als Spec,
erzeugt statt handgeschrieben.
- tests/test_vf_spec.lsp (C:TEST_VF_SPEC, in alltests.json): 7 Faelle je
Glied-Typ, 7 Validierungsfaelle, Gruppieren, und die 5 echten Ketten gegen
ihr aufgezeichnetes Journal.
- tests/test_vf_spec.py: 36 Tests (Rundlauf, Spec-Daten, Validierung,
Erwartungswert-Abgleich, Ergebnisse von VF_SPEC_BAU).
Drei Regeln, die der Uebersetzer besitzen muss - jede wuerde sonst die ganze
Replay-Queue verschieben:
- Der Menue-Code haengt am Frame: erste Sektion 4 Optionen (kein GF-Bogen,
es gibt noch keine Richtung), jede spaetere 5.
- hz steht genau EINMAL im Journal, beim ersten Segment (vfl-in-abstand
journalisiert die Richtung nur bei freier Richtungswahl).
- Nur ein HORIZONTALER Erstkoerper einer VF-Einheit stellt die Separator-/
Endpunktfragen vorab (winkel1=0 laeuft durch vfl-baue-horizontal-koerper);
ein gewinkelter wird ohne jede Frage gebaut.
Wie die Richtigkeit belegt ist - drei Implementierungen derselben Grammatik,
die einander pruefen:
- Rundlauf gegen echte Daten: journal_aus_spec(spec_aus_journal(tok)) == tok
fuer alle 5 HundM-Ketten, tokenweise numerisch verglichen. Damit ist
bewiesen, dass die Spec das Journal verlustfrei abbildet.
- Der Weg, den LISP nimmt (flaches JSON -> Spec -> Journal), ergibt separat
geprueft dieselben Journale wie das aufgezeichnete Protokoll.
- Der unabhaengige Dekoder aus lib/vf_journal_export.py verdaut alle 7
synthetischen Emitter-Ausgaben restlos, auch die zwei Zweige, die in den
echten Daten fehlen (Linie-VF, gewinkelter Erstkoerper).
- Die Erwartungswerte im LISP-Test kommen aus dem geprueften Python-Emitter;
TestLispErwartungen liest sie zurueck und vergleicht erneut. Ohne das
koennte ein Uebertragungsfehler einen falschen Erwartungswert
festschreiben und der CAD-Lauf waere gruen, obwohl der Emitter falsch
liegt.
Abweichungen von der Planung (Begruendungen in doc/TODO-plan-vf-interactive.md
Abschnitt 4.6): vsp-pruefen ruft den Emitter statt eine zweite Regelmenge zu
pflegen; das vollstaendige Journal steht nicht im Record (statt dessen
glieder_soll/glieder_ist als Desync-Detektor); Zusatzfeld segment_typ am
Glied "Linie", weil dort vfl-segment-entscheidung selbst zwischen GF und VF
waehlt; vf_ende-Werte "automatisch"/"zielpunkt-ohne-es" fuer die Faelle ohne
Frage; Praefix vsp- statt vfs- (das gehoert vf_standard.lsp).
Zusaetzlich:
- tests/test_vf_headless_statisch.py prueft jetzt auch, dass
Lisp/vf_spec.lsp UEBERHAUPT keine Eingabe-/Dialogfunktion aufruft - beim
Daten-Pfad ist die Null die Vorgabe.
- tests/testdata/mubea.json: die drei einzeln eingefuegten S-LP-Separatoren
entfernt (Fortsetzung von
|
||
|
s.ayadi
|
ba01455d52 |
[FEAT] VF-Linienzug ohne GUI/Konsole baubar (Stufe 0) + hundm05-Testfall
Ziel: eine VF_n-Kette soll aus einem Stapel Eingabedaten gebaut werden koennen - ohne Dialog, ohne Konsolenfrage. Fahrplan und Begruendungen in doc/TODO-plan-vf-interactive.md. Alle Aenderungen sind No-Ops, solange *ssg-gui-aus* und *vfl-headless* nil sind. Produktion (Lisp/vf_linienzug.lsp, Lisp/vf_core.lsp): - vfl-journal-reset im Dispatcher VOR die Modus-cond gezogen. Bisher nur im Modus-1-Zweig: ein frischer Modus-2-Lauf erbte das Journal des Vorlaufs und schrieb es in die XDATA, ein spaeterer Doppelklick spielte fremde Eingaben vor. - Lokale Variable "member" in vf-linienzug-modus2 umbenannt. Sie verdeckte im selben Scope das Builtin member, das weiter unten gebraucht wird - jedes Kletterer-Segment waere in "bad function" gelaufen. - Neu vfl-meldung: sammelt den Text nach *vfl-meldungen* + dbgmsg und zeigt ihn nur bei erlaubter GUI modal, sonst per princ. Die 12 Bau-Pfad-alerts darauf umgestellt; ein Alert blockierte sonst jeden Batch-Lauf, und sein Text ist die einzige Auskunft, WELCHE Sektion abgewiesen wurde. Die reinen Interaktiv-Alerts (fehlendes DCL, "nicht editierbar", "kein Journal") bleiben alert. - Neu *vfl-headless* (+ vfl-headless-p/-abbruch/-notausgang/-ort, Diagnose *vfl-headless-fehler*, optionaler Antwort-Hook *vfl-headless-antwort-fn*): eine erschoepfte Replay-Queue ist damit ein harter Abbruch MIT Fundstelle (Art der Eingabe, Glied- und Eingabe-Nummer) statt eines stillen Rueckfalls auf Live-Eingabe. Eingebaut in vfl-in-value, vfl-in-value-p, vfl-in-selection und vfl-in-abstand. - vfl-journal-reset loescht Meldungen und Diagnose mit (gehoeren zum Lauf); vfl-view-refresh ueberspringt headless _PLAN/_ZOOM. Testfall HundM05 (5 echte Ketten aus data/polylines.dxf): - tests/testdata/hundm05.json neu erzeugt aus den XDATA-Journalen der VF_n-Bloecke (lib/vf_journal_export.py) - flach, weil ssg-load-json zeilenweise liest. Die drei kopierten Ketten bekommen ihren echten Einfuegepunkt, nicht das veraltete HOEHE_VON-Attribut. - tests/test_hundm05.lsp arbeitet jetzt per Journal-Replay statt mit Eingabe-Mocks: ein echtes Journal fuehrt die geerbte Fahrtrichtung nicht mit (vfl-in-abstand journalisiert hz nur beim ersten Segment), ein Mock kann sie also nicht kennen. Schaltet *vfl-headless* ein und schreibt prompts, headless_fehler und meldungen ins Ergebnis-JSON. - Kettenschleife fangt je Kette: ein Fehler NACH dem Bau nimmt nicht mehr die restlichen Ketten mit. - entprev gibt es in AutoLISP nicht (nur entnext/entlast) - die Suche nach dem fertigen Block laeuft vorwaerts ab dem Zeichnungsstand vor dem Bau. Dieselbe Falle in tests/test_mubea.lsp mitbehoben; sie schlug dort nie zu, weil entlast immer sofort traf. Absicherung ohne CAD: - tests/test_vf_headless_statisch.py: eingechecktes Inventar aller alert/get*/ssget/new_dialog-Fundstellen je Funktion (ein neues getreal in einer Bau-Funktion faellt auf, auch wenn sein Zweig im Test nie erreicht wird), Praesenz des Riegels in allen vier Wrappern, Diagnose-Reset und die Reset-Reihenfolge im Dispatcher. Dazu ein Waechter gegen erfundene AutoLISP-Funktionen (entprev u.a.) - diese Fehlerklasse kostet sonst jedes Mal einen CAD-Lauf. - tests/test_hundm05.py prueft zusaetzlich prompts == 0, keine Headless-Abbrueche und keine Bau-Meldungen. tests/alltests.json: hundm05-Zeile laedt VarioFoerderer (nicht KreiselInsert) und bleibt bis zu einem gruenen CAD-Lauf abgeschaltet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
m.stangl
|
37de0d44e6 |
[DOC] tests/README.md aktualisiert (veraltete Schalter + Struktur)
- --runall gibt es nicht mehr -> --check (pytest-Validierung); an allen Stellen ersetzt (Ablauf-Diagramm, Workflow-Schritt 2, Einzelmodul-Beispiel) - --set-as-reference existiert nicht -> Referenz aktualisieren per manuellem copy output\<datei> reference\<datei>; zusaetzlich --diff_references (meld) dokumentiert - run_tests.bat hat real nur: --lisp, --check, --diff_references - Ablauf-Diagramm + Verzeichnisstruktur auf das aktuelle Modell verallgemeinert (9 Module aus alltests.json statt fester 4er-Liste; reference/ enthaelt *_results.json + *_tests_export/sivas.csv + export_raw.json, keine .dxf) - omniflo_strecke_tests.json-Beschreibung korrigiert (7 Elemente: 4 Geraden + 2 Boegen + 1 Weiche, statt des alten 12-Element-Halbkreis-Modells) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
m.stangl
|
b0aad8e8f4 |
[DOC] Neue zentrale Bausteine + Test-Infrastruktur dokumentiert
CLAUDE.md: - ssg_core: ssg-lisp-verzeichnis/-datei-pfad, ssg-rot-matrix-zy, GUI-Aus-Schalter - neue Zeile ssg_ks_insert.lsp (gemeinsame KS-Extraktion + Einfuegeprimitiven) - Lademechanismus: ssg_ks_insert in Kern-Reihenfolge (vor Gefaelle/VarioFoerderer) - VarioFoerderer: vf-dialog-ablauf/-berechnen-einfuegen + vf-winkel-solve; vf_konstanten aktiv fuer *vfk-gf-bogen-winkel*/*vfk-as-es-winkel* tests/README.md: - alltests.json: Felder module + disabled dokumentiert, Beispiel aktualisiert - Hinweis GUI-Aus (ssg-gui-aus/-an) waehrend automatischer Testlaeufe Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
m.stangl
|
60f2b72e39 |
Omniflo-Streckenzug-Test + skriptfaehige Aluprofil-Geraden
Neuer Test: 4 Geraden -> 180-Grad-Kurve (4x 45-Grad-Bogen) -> 4 Geraden als lueckenlos verketteter Streckenzug (U-Form). - testdata/omniflo_strecke_tests.json: 12 Elemente mit berechneter, verketteter Platzierung (x, y, drehung, x_ende, y_ende, Bogen-Mittelpunkt) - test_omniflo_strecke.py: Geometrie-Validierung ohne BricsCAD (Struktur, Katalog-Abgleich, Verkettung, Kurvensumme 180 Grad, gemeinsamer Mittelpunkt) - test_omniflo_strecke.lsp: C:TEST_OMNIFLO_STRECKE baut die Strecke auf - alltests.json/README.md: Test registriert und dokumentiert OmniModulInsert.lsp: omni:insert-block in skriptfaehigen Kern omni:make-gerade + omni:read-src-attribs aufgeteilt. Der Kern erzeugt eine Aluprofil-Gerade non-interaktiv aus zwei Punkten (kein getpoint/ssg-start), sodass der Test echte Gerade-Bloecke statt nackter Linien baut. Interaktives Verhalten von omni:insert-block bleibt unveraendert (Vorschau-Text, Laengenpruefung). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
m.stangl
|
3f7074f06b |
Lisp-Unit-Tests fuer reine Standardfunktionen + run_tests.bat --lisp
- tests/test_unit.lsp: Mini-Test-Framework (tu-eq/tu-eqf/tu-true/tu-nil) und Testfaelle fuer reine Funktionen aus ssg_core, ssg_lang, ssg_id, vf_core, export, Gefaellestrecke, OmniModulInsert, KreiselInsert. Befehl TEST_UNIT schreibt tests/output/unit_results.txt. - tests/test_unit.scr: Headless-Startskript (laedt SSG_LIB, ruft TEST_UNIT, beendet BricsCAD), pfadunabhaengig ueber DXFMAKRO. - bin/run_tests.bat: Schalter --lisp startet BricsCAD headless, wertet den Report aus (RESULT: OK/FAIL) und setzt den Exit-Code. - tests/README.md: Abschnitt zu den LISP-Unit-Tests. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |