79fb3df61532642416f2210976dec151ea85ef4a
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Michael StanglandClaude Opus 4.8
|
0babf78789 |
Tests + Bau-Pfad-Alert: 4 Baseline-Failures behoben
test_export_separatorliste.py (2 Failures, KeyError 'Separatorlist'): der Test pruefte noch das alte Merkmal "Separatorlist" (nur SEP-Eintraege). write_ separatorliste_merkmale fuellt seit dem Umbau das Top-Level-Feld item["trackids"] (CSV-Spalte "TrackIds") mit AS + Separatoren + ES in Baureihenfolge. Tests auf die neue API/Semantik angepasst (empirisch verifiziert: "0054, 0052, 0053, 0055"). vf_linienzug.lsp - echter Fund des statischen Waechters: vfl-body-abschluss setzte am "Kettenende nicht baubar"-Zweig ein (alert ...) im BAU-Pfad (blockiert Batch/Headless). Auf vfl-meldung umgestellt (zeigt alert nur bei erlaubter GUI, sonst princ) - genau die Regel, die der Waechter erzwingt. test_vf_headless_statisch.py (2 Failures): Soll-Inventar an den aktuellen Code angeglichen - 18 legitime neue Wizard-/Frage-Dialoge (vflw-gruppe-*-impl, vflw-m2-*-impl, vfl-frage-ist-*) + vfl-ks-aus-hz-an-punkt (ssget, Zeichnung durchsuchen) ergaenzt, vflw-gruppe-horizontal-impl entfernt (weg im Code), vfl-edit-ent auf alert:2 (linienzug2-Abweisung, harter Schnitt). Suite: 11 -> 7 failed. Verbleibend NICHT hier: test_hundm05.py (auf Wunsch ausgenommen) + test_vf_geometrie.py (6x, gebautes HundM05-DXF weicht von der Referenz ab - braucht fachliches Urteil ueber die neue Geometrie, nicht blind die Referenz ueberschreiben). 243/243 LISP-Unit-Tests gruen. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Michael StanglandClaude Opus 4.8
|
3cce1ec457 |
VF-Linienzug Modus 3 editierbar: Segment-Essenz statt Objekt-Handles
Modus 3 (Vorwaerts-Nachbau) hat jetzt dieselbe XDATA-Editierbarkeit + Doppelklick-Neubau wie Modus 1/2. Statt der Pfad-Objekt-Handles wird die abgeleitete Segment-ESSENZ journalisiert (neuer Journal-Typ SEGS): der VF_n- Block ist damit selbst-enthalten, der Neubau unabhaengig davon, ob die urspruenglichen LINE/ARC noch existieren - robuster als der OBJS-Weg von Modus 2. Journal-Kern (vf_linienzug.lsp): - Neuer Typ SEGS: Segmentliste (typ hz laenge bwinkel bseite spx spy epx epy) serialisiert als ";"-getrennte Segmente, Felder per "|". Eingebunden in vfl-entry->string / vfl-string->entry / vfl-entry->json. - vfl-in-segmente: Live (ssget -> gf-sortiere-objekte -> gf-analysiere-kette -> Eck-Vorpruefung -> 9-Feld-Essenz) ODER Replay (Essenz direkt aus SEGS-Journal). Ersetzt vfl-in-selection im Modus-3-Ablauf. - vfl-kette->segmente9 fuehrt Bau-Segmente + Start/Endpunkte zusammen; Soll-Ende kommt jetzt aus der Essenz statt aus den Original-Entities. Modus-3-Umbau: - Abbruch-Wickler + vfl-journal-xdata-schreiben mit Marker "linienzug3" (analog Modus 2). Kopf-Kommentar/Fehler-Handler-Variablen an Modus 2 angeglichen. - Kein Live-Segment-Highlight mehr (Essenz-Bau reicht keine Entity mehr durch) - bewusst, im Code dokumentiert. Doppelklick/Batch: - vfl-edit-ent2 zu vfl-edit-ent-voll parametrisiert; vfl-edit-ent3 ruft vf-linienzug-modus3. vfl-edit-ent / vfl-konvertiere-ent / vfl-journal-xdata- lesen dispatchen "linienzug3". Tests: - 8 file-freie SEGS-Roundtrip-Unit-Tests (tests/test_unit.lsp, tu-tests-vfl-segs); 234/234 LISP-Unit-Tests gruen in BricsCAD. - vfl-in-segmente im statischen Headless-Waechter registriert. - Verifiziert an einer echten linienzug3-Kette (results/test.dwg): SEGS-Journal korrekt geschrieben, Doppelklick-Neubau geometrisch deckungsgleich zum Original. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
 Samer AyadiandClaude Opus 5
|
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
|
||
|
Samer AyadiandClaude Opus 5
|
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> |