5368f5b44768c64f5170df1bcc183fb6cb69a17b
16 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 m.stangl
|
9e3e8e16ae |
fix(tests): Testlauf haengt nicht mehr an Export-Rueckfragen, Laufprotokoll je Test
TEST_LINIENZUG (ebenso hmrec:stubs-aus und vsp-headless-aus) schaltete die GUI am Ende pauschal wieder ein. Unter SSG_RUN_ALL_TESTS fragte der direkt folgende EXPORTSIVAS dann nach Hoehen-Check/Bereinigen und der Lauf blieb stehen. Alle drei stellen jetzt den Vorzustand von *ssg-gui-aus* wieder her. SSG_RUN_ALL_TESTS schaltet zusaetzlich *csv-hoehencheck-fragen* und *csv-bereinigen-vor-export* fuer den Lauf ab (unmittelbar vor jedem Export erneut, export.lsp belegt nil beim Nachladen wieder mit T), erzwingt GUI aus mit Warnung und stellt am Ende die Vorgaben wieder her. Neues Laufprotokoll DXFM_LOG/testlauf_<name>.dbg je Test (Debug-Schalter "testlauf", Standard ein): Zustand vor/nach dem Test, Fehler, Ergebnis-JSON, Export-Schritte. Eigene Datei mit sofortigem Schreiben statt dbgopen, damit die Module mit ihren eigenen .dbg-Dateien es nicht umlenken und bei einem Haenger der letzte Schritt sichtbar ist. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
 y.wang
|
4a19ac0ae0 |
refactor: Segment-Antworten als Werte, Modus-Dispatch im Spec-Pfad, Python liest Modus 2/3
Drei herausgeloeste Teile aus doc/todo/spec-modus2-3.md. Der Rest (volle
Spec-Grammatik fuer Modus 2/3, Schritte 3-5 und 7) bleibt bewusst liegen:
Modus-2/3-Journale sind durch ihren SEGS-Eintrag bereits selbst-enthalten
und ohne Zeichnung abspielbar, der Mehrwert einer Spec ist dort also klein.
1. lib/vf_journal_export.py trennt nach Marker. Modus 1 laeuft wie bisher
durch die Grammatik; "linienzug2"/"linienzug3" werden als Rohtokens
ausgegeben, im Format, das tests/test_linienzug.lsp einliest. Vorher lief
die Modus-1-Grammatik auch ueber sie (der startswith-Filter laesst sie
durch) und brach mit "Token 6: STEP erwartet" ab. Gegen die echte
Zeichnung geprueft: die Ausgabe ist identisch mit der bisher von Hand
erzeugten Testdatei.
2. vsp-bau-journal waehlt die Bau-Funktion jetzt anhand des Journals
(vsp-bau-fn-fuer-journal): kein SEGS = Modus 1, SEGS + Formatmarke
"m2v2" = Modus 2, SEGS ohne = Modus 3. Bewusst abgeleitet statt als
zusaetzliches Argument - die Funktion hat zwei Aufrufer, und AutoLISP
verlangt exakte Argumentzahl. Die Ableitung kann der Datenlage auch nicht
widersprechen, weil sie genau das Journal liest, das abgespielt wird.
3. Die Segment-Klassifizierung in Modus 2 journalisiert WERTE statt
Menue-Ziffern: Geradentyp "gf"/"vf", Bogentyp "gf-bogen"/"vario-kurve",
Variante "aussen"/"innen". Konsole UND Wizard-Dialoge legen dieselben
Werte ab. Damit deutet ein Umsortieren der Optionen keine gespeicherte
Kette mehr um - dasselbe Risiko, das beim Lauf-Anfang (
|
||
|
y.wang
|
1cc163dc11 |
feat: AS-Zufuehrungsachse fuer beide Winkel + GF-Option "Parallel zum Kreisel"
Die AS-Praeambel in Modus 1 fragt jetzt Winkel, Seite UND eine optionale Zufuehrungsachse (2. Punkt) - im Assistenten alles in einem Fenster (vflw_as_achse). Beide Angaben zusammen legen das AS vollstaendig fest: der 2. Punkt gibt die KS_EIN-Achse (Zufuehrung/Fahrtrichtung), links/rechts die AS-Variante und damit die KS_AUS-Richtung der Kette. Bisher galt die Achse nur beim 30-Grad-Element und ERSETZTE dort die Seitenfrage. Darauf setzt die neue 5. Option der gf-laenge-modus-Frage auf, intern "parallel" (vfl-gf-parallel-kreisel): AS -> GF-Stueck -> GF-Bogen aus EINEM Abstandswert, gemessen senkrecht zur Zufuehrungsachse von AS-KS_EIN bis Bogen-KS_AUS. Kein Separator dazwischen, damit der Abstand exakt getroffen wird; die Kettenende-Frage stellt der Zweig selbst NACH dem Bau. Waehlbar nur am Kettenanfang mit AS UND Achse. Der Bogen ist nicht verdrahtet: gewaehlt wird der, der den gemessenen Grundriss-Schwenk des AS-Blocks aufhebt (vf-element-plan-turn) - mit den vorhandenen Bausteinen AS 30 -> 30-Grad-Bogen, AS 90 -> 90-Grad-Bogen, immer zur Gegenseite. Querversatz von AS und Bogen wird gemessen statt gerechnet; die Bogen-Probe laeuft dabei auf dem IDEALISIERTEN 3-Grad-Rahmen, auf dem der echte Bogen spaeter sitzt (auf dem AS-Rahmen gemessen lag der Abstand im BricsCAD-Test um 0.5 mm daneben). Journal: [STR winkel][STR seite][PT p2 | NIL]. Welche Fragen gestellt wurden, wird nicht journalisiert, sondern beim Replay an der Eintragsart erkannt - alte Ketten bleiben ohne Sonderbehandlung editierbar. Die Journal-Werkzeuge (vf_linienzug_grammatik.py, vf_spec_export.py, vf_journal_export.py, vf_spec.lsp, test_hm_recformat.lsp) kennen das optionale Achsen-Token. Tests: 11 neue Unit-Tests fuer die reinen Kerne vfl-par-bogen-waehlen und vfl-par-gf-laenge (tu-tests-vfl-parallel), TEST_UNIT 701/701 gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
m.stangl
|
5aed90dd56 |
[CHANGE] doc/plan und doc/todo angelegt, interne Analyse-/TODO-Dokumente dorthin verschoben
doc/todo/: TODO-plan-vf-interactive.md -> plan-vf-interactive.md, TODO-modus2-achsenweise-bilanz.md -> modus2-achsenweise-bilanz.md (offene Fahrplaene/TODOs). doc/plan/: KS-Frame-Architektur.md, vf-parameter-struct-analyse.md, translate.md, Entwicklungsplan.md (Architektur-Analysen und Planungsdokumente, kein Anwender-Material). Alle internen Verweise (CLAUDE.md, Lisp/README.md, README.md, doc/variofoerderer.md, Lisp/vf_spec.lsp, lib/dxf_vf_abbild.py, lib/vf_spec_export.py, tests/test_hm_recformat.lsp, tests/test_vf_geometrie.py, tests/test_vf_headless_statisch.py) auf die neuen Pfade angepasst. Reine Pfad-Updates in Kommentaren/Docstrings, keine funktionale Aenderung - Python-Syntax nach dem Umbau geprueft. Anwender-/Entwickler-Referenzdoku (faq.md, kommandos.md, tools.md, dbg2lsp.md, csv-export.md, json-input-lisp.md, lisp_methods.md, LispTests.md, variofoerderer.md, vf_linienzug_modus1_anleitung.md) bleibt direkt in doc/. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
 s.ayadi
|
ba20d63f63 |
[ADD] lib/dxf_anlage_export.py: gebaute und von Hand nachbearbeitete Anlage aus der Zeichnung zurueck in Nachbau-Testdaten (Kreisel, GF, VF standard/etage, VF-Linienzug als unveraendertes Journal, Einzelbloecke) - tests/testdata/dematic_arvato.json jetzt aus Dematic_TST.dxf; [ADD] dxf_scan_components.py: Gefaellestrecken aus Staustrecken-LINEs (Layer 6-SP), Start/Ende auf die Kreisel-Ketten verlaengert, AS-Element und Separator auf der Achse werden verbraucht, Steigfoerderer erkannt, --ohne-hoehen und --kreisel-hoehe; [ADD] vf_spec.lsp: Replay-Kern vsp-bau-journal aus vsp-bau-aus-spec herausgeloest (auch fuer aufgezeichnete Journale); [CHANGE] TEST_DEMATIC_ARVATO baut GF, VF standard/etage und Linienzug-Journale (mubea:gf-bauen/-vario-bauen wiederverwendet); [FIX] GF-Winkel aus Kreisel-Hoehen: AS/ES-Abfall mit falschem Vorzeichen an gf-winkel-berechnen uebergeben (3.79 statt ~2.49 Grad, GF endete 258 mm zu tief); [ADD] Tests test_dxf_scan_gf.py, test_dxf_anlage_export.py
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
m.stangl
|
d0fe890d7c |
Start-Ausgabe entschlacken: per-Modul-Banner auf je eine Zeile kuerzen
Der SSG_LIB-Start gab ~50 Zeilen aus (mehrzeilige >>> ...geladen <<<-Banner mit Befehlslisten/Block-Pfaden, ===-Trenner, Core-Modul-Auflistung, VarioFoerderer- Typenliste). Fuer einen einfachen _QNEW-Start zu viel Rauschen. Gekuerzt (nur die dicksten Bloecke, je Modul bleibt EINE knappe Zeile; Fehler/Warnungen ALLE unveraendert erhalten): - Kern-Module (ssg_core/dbg/dialog/layer/id): reine "X geladen"-Zeilen entfernt. - Feature-Module: KreiselInsert/Gefaellestrecke/VarioFoerderer je auf eine ">>> X geladen"-Zeile; Befehlslisten, Modus-/Typen-Aufzaehlungen, Block-Pfade und ===-Trenner raus. VF-Submodule (vf_konstanten/standard/etage/linienzug/ spec) Lade-Banner ganz entfernt (der Sammel-Header deckt sie ab). - SSG_LIB_Commands "Dummy-Befehle registriert" entfernt. - menu/SSG_LIB.mnl: ===-Trenner + Core-Auflistung raus; die doppelte "Einfuege-Modus 3D"-Zeile entfernt (S:STARTUP gibt sie ohnehin einmal aus). Behalten (informativ / diagnostisch): [CFG] Config geladen: N Sektionen, [LANG] N Texte geladen, alle FEHLER/WARNUNG-Zeilen, die Abschlusszeilen "Alle Module geladen. Menue aktiv." + "Einfuege-Modus: 3D". Reine Ausgabe-Reduktion, keine Logik geaendert. 243/243 LISP-Unit-Tests gruen; alle Module laden fehlerfrei (Klammerbalance gegen HEAD unveraendert). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
s.ayadi
|
4a057862a8 |
fix: VF-Linienzug Journal-Reset, Spec-Grammatik (auf-ab/Linie-GF) und hz-Bug in HundM05
- vfl-journal-reset-lauf ans Funktionsanfang verschoben (Modus 1/2/3,
Lisp/vf_linienzug.lsp): stand bisher nach der Startpunkt/Hoehe/AS-
Praeambel und loeschte diese beim Reset selbst wieder - Journal begann
mit dem ersten STEP-Marker statt PT, betraf jede Kette.
- Spec-Grammatik erweitert (Lisp/vf_spec.lsp, lib/vf_linienzug_grammatik.py,
lib/vf_spec_export.py): "auf-ab" bei bereits flach ankommender Kette
(Richtungswahl statt Zielhoehe) und neue Linie-GF-Fragereihenfolge
(Kettenende direkt nach laenge_modus, inkl. vorgezogenem ES). Tests in
tests/test_vf_spec.lsp/.py angepasst.
- lib/vf_linienzug_grammatik.py: _linie("kettenende_ziel") erwartete
faelschlich ein hz-REAL nach der Distanz - der reale Bauablauf
(vfl-body-abschluss) leitet die Richtung dort aus dem Frame ab und
fragt sie nie. Fuehrte zu einem Token-Desync beim Dekodieren echter
Kettenende-Journale.
- tests/testdata/hundm05.json (VF_hundm05_LZ_01): 5 ueberfluessige
hz-Felder entfernt. vsp-linie injiziert bei JEDEM vorhandenen hz-Feld
einen Richtungs-Token, unabhaengig vom tatsaechlichen Bauablauf - die
Felder desyncten den Replay und liessen die Kette stumm mit der
falschen (verkuerzten) Geometrie fertig bauen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
s.ayadi
|
23d79ec354 |
feat: eingang_hoehe="auto" auf Python-Seite nachgezogen, hundm05.json bereinigt
Lisp (vf_linienzug.lsp/vf_spec.lsp): - vsp-eingang-hoehe unterstuetzt jetzt "auto" (NIL-Token statt REAL) - bewusst keine Zahl vorgeben, der Bauablauf berechnet seinen eigenen Vorschlag, wie bei leerer Konsoleneingabe - vfl-journal-reset-lauf: internes Reset innerhalb von vf-linienzug-modus/ -modus2 loescht *vfl-replay-queue*/*vflw-pending* nicht mehr mit (Bug: REPLAY-getriebener Bau (vsp-bau-aus-spec) brach mitten in der Kette ab, weil eine noch unverbrauchte Queue verworfen wurde) Python-Gegenstueck nachgezogen (lib/vf_linienzug_grammatik.py, lib/vf_spec_export.py, lib/vf_journal_export.py): - NIL-Token-Unterstuetzung fuer eingang_hoehe="auto" im gemeinsamen Parser-Kern, im Schreiber (SpecSchreiber) und in der Protokoll-Annotation - gf_verteilung ist im Schreiber jetzt an der Feldpraesenz in der Spec festgemacht statt an einem Grammatik-Flag (selbstbeschreibend, deckt Specs mit und ohne diese Frage ab, ohne dass der Aufrufer die Grammatik kennen muss) - Rundlauf-Pruefung (main(), test_verlustfrei) toleriert jetzt die bekannte, schon dokumentierte Erweiterung um drei neue Linie-GF-Pflichtfragen (ist_teilfolge statt exakter Gleichheit) - test_gleiche_journale_wie_protokoll: alle 5 Ketten in hundm05.json weichen inzwischen vom Rohprotokoll ab (Kette 1 bewusst wegen eingang_hoehe, Ketten 2-5 schon laenger wegen Handkorrektur gegen echte DXF-Positionen) - expliziter Skip mit Begruendung statt leerem Loop tests/testdata/hundm05.json: - mm-Werte (dl, Start-/Stuetzpunkte, Koordinaten der Nachtrag-Objekte) auf eine Nachkommastelle gerundet - nicht abgefragte Kopf-Metadaten entfernt (beschreibung, sivas_id, sivas_bezeichnung, planquadrat, block, dxf_handle) - nur quelle bleibt Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
s.ayadi
|
1bdecf0678 |
fix: Horizontal-VF-Kettenanfang (eingang_hoehe) in vsp-journal nachgezogen, hundm05.json erneuert
vf-linienzug-modus fragt bei einem mit "Horizontal-VF" eroeffneten Kettenanfang eine Ziel-Hoehe fuer den GF1-Einlauf ab (vfl-prompt-hoehe- eingang-gf1) und laesst dort die GF-Verteilungsfrage weg (fest "alles am Einlauf") - vsp-journal/vsp-vf-einheit kannten das noch nicht. Ausserdem werden ES-Winkel/-Seite beim kettenende-sub jetzt an der richtigen Journal-Position (inkl. eigenem STEP-Marker) emittiert. tests/testdata/hundm05.json: VF_hundm05_LZ_02..05 (die vier baugleichen Schleifen, Block VF_1) aus tests/testdata/linienzug_tests.json neu abgeleitet, mit den realen Startkoordinaten aus results/test_hundM05.dxf statt der alten "sub":"auf-ab"-Behelfsloesung. VF_hundm05_LZ_01 und alle Kreisel-/Separator-/Scanner-/BTMT-Objekte unveraendert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
y.wang
|
4418840d5e |
fix: berechne-alle-winkel Signatur-Nachzug (schon-flach) + HundM05-Menu-Fix nachgezogen
Lisp/vf_standard.lsp: berechne-alle-winkel um Parameter schon-flach erweitert (Fussabdruck-Korrektur, wenn ein Frame flach statt bei 3 Grad ankommt) - vf_linienzug.lsp rief die Funktion bereits mit diesem 5. Argument auf, dieser Commit fehlte im letzten Commit und liess den Zwischenstand mit Argumentzahl-Mismatch zurueck. tests/test_foerderer.lsp und tests/test_mubea.lsp ziehen dieselbe Signatur nach (inkl. berechne-horizontale-mitte, das schon-flach bereits erwartete). tests/testdata/linienzug_tests*.json aktualisiert passend zum echten Bau-Ablauf. menu/SSG_LIB.mnu/.cui: TEST_LINIENZUG_STUFE2 im Testmenue ergaenzt. Lisp/vf_spec.lsp + lib/vf_spec_export.py: *vsp-menu-start* auf die aktuelle 6-Optionen-Kettenanfang-Zuordnung umgestellt (vorher noch 4 Optionen) - vsp-journal replayt gegen den LEBENDEN vf-linienzug-modus. Python-Tabelle bewusst NICHT umgestellt (dekodiert eine eingefrorene Alt-Aufzeichnung). TEST_HUNDM05 schlaegt trotzdem weiterhin fehl (separates, ungeloestes Problem - siehe naechster Absatz). Bekannter offener Fehler: TEST_HUNDM05 baut nach wie vor nicht korrekt - der Menu-Code-Fix allein reicht nicht. Root Cause nicht abschliessend geklaert, Uebergabe an Kollegen fuer Logik-Review vorgesehen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
y.wang
|
0a1d21d8c5 |
fix: VF-Linienzug 100%-Wiederherstellung aus e76e24e abgeschlossen
Restauriert alles aus
|
||
|
y.wang
|
23d653c4b3 |
feat: VF-Linienzug Linie-GF - Separator VOR/NACH, Endpunkt/Zielhoehe-Vorwahl, steigende GF (Sonderfall bis 3 Grad)
Auf der neuen Kollegen-Architektur (Stufe 0-2: Spec/Journal/Replay-System
in vf_spec.lsp, Frage-Schale/Bauteil-Trennung) neu aufgebaut, nachdem der
urspruengliche Stand (Commit
|
||
|
s.ayadi
|
2dd5382060 |
[FEAT] Weitere Objekte der Anlage in hundm05.json bauen (Kreisel)
tests/testdata/hundm05.json enthaelt jetzt neben den 5 Spec-Ketten auch andere Objekte der Anlage - erkennbar am Feld "function", im Format der jeweiligen Einzel-Testdaten (ein Kreisel also wie in kreisel_tests.json). Damit beschreibt EINE Datei die ganze Anlage. - tests/test_hundm05.lsp: hundm05:bau-zusatzobjekte sammelt alle Objekte mit "function" und baut sie; hundm05:bau-kreisel ruft kreisel-insert-script (wie tests/test_kreisel.lsp) und liefert einen Ergebnis-Record in derselben Form wie die Ketten. Eigener ssg-start-Rahmen mit ATTREQ/ATTDIA 0, weil vsp-bau-datei seinen schon geschlossen hat und (command "_.INSERT" ...) sonst nach Attributwerten fragt. Je Objekt gefangen, damit ein Fehler die restlichen nicht mitnimmt. - Lisp/vf_spec.lsp: "kind" ist jetzt ein Record-Feld (Default "linienzug") statt eines Literals in vsp-result-json - so schreibt vsp-results-schreiben beide Objektarten in EINE Ergebnisdatei. - lib/vf_spec_export.py: Objekte der Ziel-Datei, die keine Kette beschreiben, werden beim Neuschreiben unveraendert ans Dateiende uebernommen. Ohne das waere jeder von Hand ergaenzte Eintrag beim naechsten Generatorlauf weg - die Datei ist erzeugt UND handgepflegt. spec_aus_flachen_objekten ueberspringt sie jetzt statt zu werfen, genau wie vsp-gruppieren in LISP. - tests/test_hundm05.py: die Ketten-Tests filtern auf kind "linienzug" (Records ohne das Feld stammen aus aelteren Laeufen und waren nur Ketten); neue Klasse TestZusatzobjekte prueft Status, expect_block_prefix, expect_hoehe (Attribut HOEHE), expect_kreiselart (KREISELART) und den Einfuegepunkt - dieselben Erwartungsfelder wie tests/test_kreisel.py. - tests/test_vf_spec.py: neuer Test, dass die Zusatzobjekte die Ketten-Zerlegung nicht beeinflussen - auch nicht, wenn sie mitten zwischen den Sektionen stehen (der eingetragene Kreisel stand zunaechst inmitten der Sub-Knoten von Kette 5; nach dem Regenerieren steht er am Dateiende). Verifiziert: 118 pytest-Tests gruen, Spec-Regenerierung uebernimmt das Zusatzobjekt (58 Objekte), beide .lsp lint-sauber. Die Kreisel-Tests warten auf den naechsten TEST_HUNDM05-Lauf. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
s.ayadi
|
02303ad7fc |
[REFACTOR] Stufe 2, Schritte 0-4: Frage-Schale und reinen Bauteil trennen
Alle Aenderungen sind verhaltensgleich: die Frage-Schalen behalten ihre Namen, keine Aufrufstelle in Modus 1/2/3 wurde angefasst. Schritt 0 - vfl-ziel-report: der Soll-Ist-Vergleich am Kettenende stand zweimal WORTGLEICH in vfl-vf-einheit-abschluss (einmal fuer "Kettenende ohne ES", einmal "mit ES"); die Faelle unterscheiden sich nur darin, wann sie melden, nicht was. Schritt 1 - Winkelwahl aufgeteilt: vfl-winkel-gueltige (Kandidaten filtern) und vfl-winkel-nach-index (Kandidat waehlen) sind rein; die Frage-Schale vfl-waehle-winkel setzt sie zusammen. Neuer Vorgabe-Kanal *vfl-winkel-idx-vorgabe*: ist er gesetzt, wird nicht gefragt. Kanal statt Parameter, weil vfl-waehle-winkel aus vier Solvern gerufen wird (vfl-vf-winkel, vfl-vf-entscheidung, vfl-body-zerlegung, vfl-segment-entscheidung) - ein Parameter wuerde vier Signaturen und alle deren Aufrufer aendern. Default nil, also heute ohne Wirkung. Schritt 2 - vfl-es-masse-setzen: reines Globals-Setzen (ES-Winkel merken + vf-set-es-masse) aus vfl-frage-es-seite gezogen. *vfl-es-winkel* wird LAZY von den Blocknamen-Bauern gelesen und muss vor dem ersten ES-Insert stehen. Schritt 3 - vfl-hor-koerper-bauen: die drei Fragen (Separator vor/nach, Endpunkt) haengen an keinem berechneten Wert und stehen jetzt alle vor dem Bau. Journal-Reihenfolge UND Entity-Reihenfolge bleiben identisch; nur interaktiv erscheint der auf_3-Uebergangsblock erst nach den drei Fragen statt zwischen Frage 1 und 2. Die dL-Subtraktionskette wurde Zeile fuer Zeile uebernommen - jeder Schritt ist mit (max *vfk-restlaenge-min-clamp* ...) geklammert, also nicht kommutativ, und der auf_3-Insert sitzt bewusst zwischen Subtraktion 1 und 2 (sein Fussabdruck wird GEMESSEN). Nachweis: Zeilenvergleich alt/neu, dieselben 15 geometrie-relevanten Zeilen in derselben Reihenfolge. Schritt 4 - vfl-body-abschluss-bauen: hier laesst sich NICHT alles vorab fragen (vfl-neue-linie-messen braucht den Frame nach vfl-nach-3grad, die Hoehenvorschlaege brauchen dL und die Kettenhoehe). Die Schale macht darum 3-Grad-Abschluss -> messen -> Vorschlaege -> Zielhoehe fragen, der reine Teil beginnt bei der Zerlegung. Nachweis: Multiset-Vergleich der Zeilen, ausser Kopf, Klammer und Aufruf ist keine Zeile veraendert. Schritt 7 (Assertion-Teil) - vsp-journal-diff in Lisp/vf_spec.lsp: stellt das aus der Spec erzeugte Journal Token fuer Token gegen das beim Bau neu aufgezeichnete. Schaerfster Desync-Detektor - offene Queue-Werte und die Glied-Folge zeigen nur grobe Abweichungen, ein einzelner Wert, der an der falschen Stelle verbraucht wird, kann beide passieren lassen und trotzdem andere Geometrie erzeugen. Neues Record-Feld journal_diff, neuer Test test_journal_token_gleich. Zwei bewusste Abweichungen von der Planung (begruendet in doc/TODO-plan-vf-interactive.md, Abschnitt "Umsetzungsstand Stufe 2"): vfl-hor-koerper-bauen behaelt ziel-modus als eigenen Parameter neben ende-code (ende-code darf nil sein, die Separator-Subtraktionen haengen aber allein am Ziel-Modus); vfl-body-abschluss-bauen braucht letzt-hz und es-gewuenscht nicht. Offen: Schritte 5, 6, 8, 9, 10. Das sind die, bei denen die Reihenfolge selbst Geometrie ist - der Fahrplan verlangt nach jedem einen CAD-Lauf (TEST_HUNDM05 + TEST_VF_SPEC + TEST_LINIENZUG), nach den Geometrie-Schritten zusaetzlich DXF-Diff und Sivas-Export-Vergleich. Ohne Lauf zwischen den Schritten waere ein Fehler nicht mehr einem Schritt zuzuordnen. Sie bringen keine neue Faehigkeit: der Bau aus Daten laeuft seit Stufe 1 und ist mit VF_SPEC_BAU belegt (5 OK, 0 Fehler). Verifiziert: 109 pytest-Tests gruen, beide .lsp lint-sauber, kein neuer alert/get*/ssget im Bau-Pfad (statischer Waechter). 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
|