b8e8d0b0a0149f122dad27b1a2ed1c9cdfdbd8ee
13 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 y.wang
|
e1e5fbf0c1 |
feat: Modus 3 mit optionalem AS/ES, ES-Frage vor dem Bau; Helfer rollenbasiert benannt
WARUM MODUS 3 BLEIBT
Modus 2 und 3 arbeiten beide auf einem gezeichneten Pfad (LINE/ARC), aber sie
loesen verschiedene Aufgaben:
Modus 2 = Randwertproblem - Start UND Ziel (je X/Y/Z) sind bekannt, die
Zwischenhoehen werden gerechnet, die Zielhoehe wird exakt
getroffen.
Modus 3 = Anfangswertproblem - die Kette wird mit vorgegebenen Winkeln
vorwaerts durchgebaut, die Endhoehe ist das ERGEBNIS.
Modus 3 kann damit etwas, was Modus 2 grundsaetzlich nicht kann: ohne
vorgegebene Zielhoehe arbeiten ("folge dieser Linie mit 3 Grad und lass uns
sehen, wo wir landen") - und er hat keinen Solver, der scheitern kann.
Dazu kommt ein harter Bestandsgrund: Modus 3 schreibt ein eigenes Journal
(Marker "linienzug3") und ist per Doppelklick editierbar. Faellt der Code
weg, verlieren alle bereits damit gebauten Ketten ihren Editier-Pfad.
Der Stempel "Legacy / wird umgebaut" war ueberholt und ist raus.
MODUS 3 - DREI AENDERUNGEN (Nutzer-Vorgabe 2026-10-22)
1. "AS bauen?" und 2. "ES bauen?" sind jetzt abfragbar (vorher wurden beide
immer gebaut), zusammen mit Winkel und Seite in je EINEM Dialog - dasselbe
Muster, das Modus 2 schon nutzt (vflw-gruppe-as-impl), kein neuer Code.
Ohne AS beginnt die Kette direkt am Startpunkt (flacher Rahmen statt
Block); die Fussabdruck-Trimmung der ersten Geraden rechnet dann von
selbst 0, weil Rahmen und Startpunkt zusammenfallen.
3. Die ES-Frage steht jetzt VOR dem Bau. Das behebt einen echten Fehler: die
letzte Gerade wird um "Separator + ein-dx" gekuerzt, ein-dx wurde aber
gelesen, BEVOR es gesetzt war - beim ersten Lauf griff der Schaetzwert
*vfk-as-es-fallback-dx*, bei jedem weiteren stand dort der Wert der
VORHERIGEN Kette (falscher Winkel, falsche Seite). Jetzt traegt die
Trimmung den echten Fussabdruck der gewaehlten ES-Variante; ohne ES
entfaellt sie ganz.
ABWAERTSKOMPATIBILITAET
Das Verschieben der ES-Frage aendert die Journal-Reihenfolge. Bestehende
"linienzug3"-Ketten bleiben per Doppelklick nachbaubar: alt-journal erkennt
sie am WERT des ersten Antwort-Eintrags ("30"/"90" = alt, "1"/"2" = neu, die
Mengen sind disjunkt) und spielt sie in der alten Reihenfolge ab. Dafuer der
neue Helfer vfl-replay-peek-wert neben vfl-replay-peek-art.
DIALOG vflw_as
Die Seitenauswahl wurde bei 30 Grad ausgegraut und NICHT in die Pending-Queue
gelegt - eine reine Modus-1-Regel (dort ersetzte die Zufuehrungsachse die
Seitenfrage). Modus 1 hat seit 2026-10-21 seinen eigenen Dialog; uebrig
blieben ES-Element sowie Modus 2/3, wo die Seite IMMER gebraucht wird - dort
ging bei 30 Grad ein zweites Fenster nur fuer die Seite auf. Entfernt.
NAMENSSCHEMA (faellt in denselben Commit, weil dieselbe Datei)
Die Helfer-Praefixe vfl2-/vfl3- stammten aus einer Planungsphase vor der
endgueltigen Menue-Zuordnung und waren dazu VERTAUSCHT: alle vfl3-* gehoeren
zu Modus 2, die vfl2-* zu Modus 3 - und drei davon zu BEIDEN. Eine
Modus-Nummer war fuer diese drei also gar nicht richtig vergebbar. Sie heissen
jetzt nach ihrer Rolle: vfl-zsolve-* (rechnet die Hoehen durch, nur Modus 2)
und vfl-pfad-* (arbeitet am gezeichneten Pfad, Modus 2 UND 3). 18 Funktionen,
jede Aufrufstelle maschinell gegen die Definitionen geprueft. Die falsche
Block-Ueberschrift "MODUS 3: Pfad + Ziel-Hoehe" (gemeint war Modus 2) ist
korrigiert, beide Gruppen haben jetzt einen erklaerenden Kopf.
vfl-zsolve-bruecke (frueher vfl3-solve-bruecke) wird von niemandem aufgerufen
- bewusst stehen gelassen und markiert, Loeschen gehoert in ein
Tote-Code-Review.
MENUE
Die Modi heissen jetzt nach ihrem Unterschied statt nach der Bedienung:
"aus 3D Linie mit Zielhoehe" / "aus 3D Linie ohne Zielhoehe" (vorher
"3D Objekte stueckweise (in Arbeit)").
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
 m.stangl
|
01fb2d29f2 |
[CHANGE] GEFAELLESTRECKE_LINIENZUG-Streckengruppen per Doppelklick editierbar machen
Bisher brach GEFAELLESTRECKE_EDIT bei jeder Streckengruppe (TYP "Streckengruppe", d.h. mit mindestens einem Bogen) mit "Nur einfache Gefaellestrecken..." ab - Grund war nicht fehlende Technik, sondern dass gf-linienzug-modus schlicht keine Edit-XDATA schrieb (anders als Modus 1/2 ueber SSG_GF_EDIT). Neue XDATA-App SSG_GF_LZ (gf-lz-xdata-schreiben/-lesen in Lisp/Gefaellestrecke.lsp) sichert die Segmentliste (Typ/hz/Laenge/Winkel/Seite je Segment, bereits laengenfertig) + den Baustartpunkt - Serialisierung per gf-segmente->string/gf-string->segmente, Chunking ueber die bestehenden ssg-sepliste-chunk-string/-split-feld/-explode-chars-Helfer aus ssg_ks_insert.lsp (wiederverwendet statt dupliziert). Neue Funktion gf-linienzug-rebuild: baut die Kette am selben Startpunkt neu, AS-/EIN-Element und Gefaellewinkel bleiben ueber dieselben zwei Dialoge wie beim Bauen editierbar (gf-dialog-linienzug-aus-ein/-winkel, jetzt mit prefill-Parameter fuer den Edit-Fall statt Defaults) - die Segmentlaengen/-form selbst nicht (dafuer bleibt GEFAELLESTRECKE_LINIENZUG als Neubau). c:GEFAELLESTRECKE_EDIT dispatcht vor der bisherigen TYP-Sperre: Streckengruppe MIT SSG_GF_LZ-XDATA -> neuer Rebuild-Pfad, Streckengruppe OHNE (Altbestand/VF-Kombi) -> bleibt wie bisher abgewiesen. Alter Block wird erst NACH erfolgreichem Neuaufbau geloescht. doc/variofoerderer.md um den Edit-Ablauf ergaenzt. Manuell in BricsCAD getestet (Doppelklick auf Linienzug-Streckengruppe, beide Dialoge vorbelegt, Neuaufbau, erneuter Doppelklick auf das Ergebnis) - laeuft. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
m.stangl
|
a9cdc127d9 |
[CHANGE] GEFAELLESTRECKE_LINIENZUG: AS/ES-Auswahl und Gefaellewinkel per Dialog statt Konsole (Teil B der GUI-Umstellung)
Zwei neue Dialoge (dcl/gefaellestrecke.dcl, Lisp/Gefaellestrecke.lsp): - gf-dialog-linienzug-aus-ein: AUS-/EIN-Element Winkel+Seite in EINEM Dialog, ersetzt die vier fruehen Konsolenfragen. Muss vor der Segmentlaengen-/Winkelberechnung laufen (haengt von AS-/ES-Masse ab), darum eigener, fruehzeitiger Dialog. - gf-dialog-linienzug-winkel: zeigt den automatisch aus der Segmentkette berechneten Gefaellewinkel-Vorschlag ueberschreibbar, mit kurzer Segment-Zusammenfassung und dem bereits gewaehlten AS/ES-Paar nur noch zur Kontrolle (disabled). Ersetzt zugleich die SPAETERE finale Einfuegen-Bestaetigung - nach der rein automatischen AS/ES-Korrekturschleife waere eine zweite Rueckfrage redundant. Objektauswahl (ssget LINE/ARC) und Start-/Endpunktwahl bleiben bewusst Zeichnung/Konsole. Rueckfall auf die alten Konsolenfragen bleibt erhalten, wenn ein Dialog nicht gezeigt werden kann/darf (GUI aus); ein bewusster Dialog-Abbruch bricht dagegen den ganzen Befehl ab statt auf Konsole zurueckzufallen - neu im Vergleich zum alten Verhalten, aber konsistent mit vfc_eingabemodus/vfs_nachruesten_hz aus Teil A/C. doc/variofoerderer.md (Abschnitt 4) aktualisiert und um einen bebilderten Beispiel-Walkthrough ergaenzt (gf-linienzug1-3.png: Ausgangslinie, Dialog mit Vorschlagswinkel, fertige Strecke neben der Original-Linie). Manuell in BricsCAD getestet (vollstaendiger Lauf inkl. Abbruch in beiden Dialogen) - laeuft. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
m.stangl
|
57bb1e9057 |
[CHANGE] VARIOFOERDERER_NACHRUESTEN: Baurichtung per Dialog statt Konsole (Teil C der GUI-Umstellung)
Neuer Dialog vfs_nachruesten_hz (dcl/variofoerderer.dcl) + vfs-dialog-nachruesten-hz (Lisp/vf_standard.lsp) ersetzt den fruehren getreal-Prompt. Zeigt pro unmarkiertem VF_n-Fund Blockname/erkannten Typ und ein hz-Feld, vorbelegt mit dem zuletzt eingegebenen Wert (identisches Default-Fortpflanzungs-Verhalten wie vorher). "Abbrechen" im Dialog uebernimmt bewusst nur den Vorgabewert fuer DIESEN Fund (Rueckgabe 'ABBRUCH), statt die ganze Nachruesten-Schleife abzubrechen oder auf die Konsole zurueckzufallen - echter Konsolen-Rueckfall bleibt ausschliesslich fuer den Fall, dass der Dialog gar nicht gezeigt werden kann (GUI abgeschaltet). Die Objektauswahl (ssget) selbst bleibt unveraendert Zeichnung/Konsole. doc/variofoerderer.md um den Befehl ergaenzt (war dort bisher gar nicht erwaehnt). Manuell in BricsCAD getestet (unmarkierter VF_4-Block, Dialog erscheint, hz=0 markiert) - laeuft. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
m.stangl
|
9a7907ab00 |
[CHANGE] VF Standard/Etage 3D-Linie-Eingabemodus per Dialog statt Konsole (Teil A der GUI-Umstellung)
Neuer Dialog vfc_eingabemodus (dcl/variofoerderer.dcl) + vfc-dialog-eingabemodus-waehlen (Lisp/vf_core.lsp), analog zum bestehenden vfc_typ-Muster: Radio-Buttons "3D-Linie auswaehlen" / "Werte manuell eingeben" ersetzen die fruehere getstring-Konsolenabfrage in vf-dialog-ablauf. Betrifft StandardVarioFoerderer3D und EtageVarioFoerderer3D (beide rufen denselben Ablauf). Die 3D-Linie-Objektauswahl selbst (vfc-3dlinie-erfassen) bleibt bewusst Zeichnung/Konsole - eine Linie laesst sich nicht durch ein Formularfeld ersetzen. Alle daraus abgeleiteten Werte (deltaL/deltaH/hz/Einfuegehoehe) gehen als Prefill in den bereits bestehenden Basis-Dialog (variofoerderer_basis), der sie ueberschreibbar anzeigt - identisch zum "Werte manuell"-Pfad. Rueckfall auf die alte Konsolenabfrage bleibt erhalten (GUI abgeschaltet, DXFM_LANG=en_GB), wie bei vfc_typ. doc/variofoerderer.md (Abschnitt 2, 8, Entscheidungsbaum) und CLAUDE.md entsprechend aktualisiert. Manuell in BricsCAD getestet (StandardVarioFoerderer3D + EtageVarioFoerderer3D, beide Dialogzweige inkl. Abbruch) - laeuft. Co-Authored-By: Claude Sonnet 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
|
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> |
||
|
s.ayadi
|
04a12e5981 |
[FIX] VF-Linienzug: Abbruch beim Editieren brach den VF-Block auf
Die interaktiven Editier-Pfade riefen den Neuaufbau ueber vl-catch-all-apply auf. Der alte Block ist dort per entdel schon entfernt, und der Catch faengt einen Abbruch (ESC -> (exit)) VOR *error* ab - der Abbruch-Wickler vfl-modus-abbruch-sichern kam damit nie zum Zug. Ergebnis: die komplette Kette blieb als lose Einzelteile ohne VF_n-Block liegen und war nicht mehr per Doppelklick editierbar. - vfl-edit-ent (Sektions-Zweig) und vfl-edit-ent2 rufen vf-linienzug-modus/-modus2 jetzt DIREKT auf. Nur der nicht-interaktive Batch-Konverter vfl-konvertiere-ent behaelt den Catch (die Batch-Schleife muss weiterlaufen) und meldet den betroffenen Block statt still zu scheitern. - Beide Abbruch-Handler setzen *ssg-ils-dim* zurueck. Das tat bisher nur der Aufrufer, der nach einem Abbruch nicht mehr erreicht wird - der Dim-Override blieb fuer die restliche Sitzung stehen. Wiederherstellung aus der Zeichnung (Sektions-XDATA): - vfl-segment-xdata-sichern schrieb nur die Slice des LETZTEN Glieds einer Schleifen-Iteration. Eine VF-Einheit mit eingebetteten Vario-Kurven verlor dadurch ihre eigenen Eingaben. Jetzt wird der komplette Journal-Abschnitt der Iteration geschrieben, indiziert mit dem ersten Glied-Index darin (neu: vfl-journal-ab-glied, vfl-steps-zaehlen). Ein Glied ohne Geometrie verbraucht seinen Abschnitt nicht mehr - er wandert in den naechsten Record, der Entities bekommt. - Neue XDATA-App SSG_VF_EDIT_PRE haelt die Praeambel (Startpunkt, Starthoehe, AS ja/nein + Winkel/Seite) auf den Entities der ersten Iteration. Ohne sie fehlte der Kopf des Journals in jeder Sektion. - Neuer Befehl VF_SEKTION_RESTORE: Auswahl der losen Geometrie -> Sektionen lueckenlos ab Glied 1 zusammensetzen -> stummer Replay -> interaktiv weiterbauen. Die alte Geometrie wird erst NACH erfolgreichem Neuaufbau geloescht, ein Abbruch laesst sie samt XDATA stehen (Versuch wiederholbar). Altbestand ohne Praeambel-XDATA wird danach gefragt. Die .dbg-Dateien bleiben reine Ausgabe und werden von keinem Befehl gelesen - Wiederherstellungs-Daten gehoeren in die XDATA der Zeichnung. tests/testdata/vfl_journal_hm05_abbruch.json: Journal der Session vom 2026-08-31 (9 Glieder), gegen das die Slice-/Join-Logik geprueft wurde. Reine Daten, wird von keinem Befehl gelesen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
m.stangl
|
1d19121679 |
[FEAT] VF-Linienzug Modus 2+3: Segment-Gruppen-Dialoge + Highlight
Modus 2 (Pfad+Zielhoehe) und Modus 3 (Vorwaerts-Nachbau) fassen die je Segment unmittelbar aufeinanderfolgenden Fragen (Typ + ggf. Neigung/ Vario-Winkel/Variante) in EINEM Wizard-DCL-Dialog zusammen - analog zu Modus 1. Der Dialogkopf zeigt "Segment i/n ..."; das aktuelle Pfad-Segment (LINE/ARC) wird vorher per redraw-Highlight in der Zeichnung hervorgehoben. - Neue DCL-Dialoge: vflw_seg_linie_m2, vflw_seg_linie_m3, vflw_seg_bogen - Neue Helfer: vflw-seg-*-impl (fuellen *vflw-pending*), vfl-seg-highlight, vfl-seg-kopf - Modus 3 zusaetzlich: Kettenstart- und AS-Element-Gruppen-Dialog; AS-Winkel jetzt pending-aware ueber vfl-in-value - Bogen-Dialog: vario-erlaubt-Flag (Modus 3 nur im offenen VF-Lauf), sonst wuerde die unkonsumierte Variante-Antwort ins naechste Segment lecken Alles hinter (vfl-wizard-aktiv) - bei GUI-aus (Tests) faellt alles unveraendert auf Konsole/Replay zurueck. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
m.stangl
|
c9ce3bbe4a |
doc: Wizard-Dialog zeigt echte Frage statt generischem Menuetext
frage-key-Parameter (vfl-menu/vfl-menu-int -> *vflw-menu-frage* -> vflw-wahl) dokumentiert, der die Dialog-Kopfzeile mit der eigentlichen Frage statt "Ihre Wahl (1/2/3)..." befuellt. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
m.stangl
|
e3dbaceb24 | Wizard mit Oberflächenstückwerk für den Mode 3 für den VF gebaut |