[ADD] dbg2lsp.py: AutoLISP-Funktionen automatisch mit ssg_dbg instrumentieren

Neues Entwickler-Tool (bin/dbg2lsp.bat + lib/dbg2lsp.py), das das manuelle
Einfuegen von dbgf/dbg/dbgreturn/dbgopen/dbgclose automatisiert:
- --method NAME: dbgf + dbg je Parameter + dbgreturn um die letzte Rumpf-Form
- --recursive: verfolgt den Aufrufgraphen ueber Dateigrenzen hinweg (Builtins
  werden automatisch uebersprungen, da sie kein defun im Suchpfad haben)
- --add-open DATEI METHODE: dbgopen/dbgclose fuer einen Einstiegspunkt
  (z.B. ein c:BEFEHL-Kommando), inkl. aller (exit)-Stellen
Dokumentiert in doc/dbg2lsp.md, Kurzeintrag in CLAUDE.md.

Ausserdem: set_attributs.py aus doc/tools.md und CLAUDE.md entfernt - das
Skript existiert nicht mehr in lib/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-28 15:04:45 +02:00
parent 1d5d7c141e
commit d7bcfc3edb
5 changed files with 949 additions and 167 deletions
+206
View File
@@ -0,0 +1,206 @@
# dbg2lsp
Instrumentiert AutoLISP-Funktionen (`.lsp`) automatisch mit den `ssg_dbg.lsp`-Routinen
(`dbgf`, `dbg`, `dbgreturn`, `dbgopen`, `dbgclose`) - so wie es beim manuellen Debuggen
bereits von Hand gemacht wird (siehe z.B. `Lisp/KreiselInsert.lsp::ils-eckrad-insert`).
Erspart das muehsame und fehleranfaellige manuelle Einfuegen dieser Aufrufe in
lange Aufrufketten (Kreisel/VarioFoerderer/Gefaellestrecke/Separator-Scanner o.ae.),
bevor ein Testlauf in BricsCAD gestartet wird.
- [Aufruf](#aufruf)
- [Was wird eingefuegt](#was-wird-eingefuegt)
- [--method](#--method)
- [--recursive](#--recursive)
- [--add-open](#--add-open)
- [Schalter](#schalter)
- [Typischer Ablauf](#typischer-ablauf)
- [Beispiele](#beispiele)
- [Funktionsweise / Aufloesung](#funktionsweise--aufloesung)
- [Grenzen](#grenzen)
- [Idempotenz](#idempotenz)
## Aufruf
```
bin\dbg2lsp.bat <datei.lsp> [--method NAME ...] [--recursive] [--add-open DATEI METHODE] [Schalter]
```
Das Batch-Skript ruft `setenv.bat` auf und startet `lib/dbg2lsp.py` mit den
uebergebenen Argumenten. `<datei.lsp>` dient als Anker (ihr Verzeichnis wird immer
mitdurchsucht) - die gesuchte Funktion muss nicht zwingend in genau dieser Datei
stehen, siehe [Funktionsweise](#funktionsweise--aufloesung).
## Was wird eingefuegt
### --method
Fuer die angegebene Funktion (mehrfach angebbar) wird direkt als erste Rumpf-Form
```lisp
(dbgf "funktionsname")
(dbg 'parameter1)
(dbg 'parameter2)
...
```
eingefuegt (ein `dbg`-Aufruf je Eingabeparameter - die Locals nach `/` in der
Parameterliste NICHT, das sind keine Eingabewerte), und die **letzte Form des
Funktionsrumpfs** wird eingeklammert:
```lisp
(dbgreturn <letzte Rumpf-Form>)
```
`dbgreturn` loggt und liefert den Rueckgabewert unveraendert weiter (siehe
`Lisp/ssg_dbg.lsp`) - das Verhalten der Funktion aendert sich dadurch nicht.
### --recursive
Verfolgt zusaetzlich den Aufrufgraphen: jede Funktion, die im (Original-)Rumpf
aufgerufen wird - auch beliebig verschachtelt, z.B. in einem `if`/`progn`, aber
NICHT innerhalb einer `'quotierten Liste` (die ist reine Datenliste, z.B.
`'(("OSMODE") ("CECOLOR"))`) - wird ebenfalls mit `--method`-Logik instrumentiert,
sofern sich ihr `(defun ...)` in einem der durchsuchten Verzeichnisse findet.
AutoLISP-/BricsCAD-Builtins (`princ`, `command`, `strcat`, `rtos`, `entmake`, `vla-*`, ...)
haben dort naturgemaess kein `defun` und werden dadurch automatisch **nicht** angefasst -
es gibt keine Builtin-Blacklist zu pflegen. Die `ssg_dbg.lsp`-Funktionen selbst
(`dbgf`, `dbg`, `dbgp`, `dbgmsg`, `dbgreturn`, `dbgopen`, `dbgclose`, `dbgflush`, `dbgon`, `dbgoff`
und ihre internen `dbg-*`-Helfer) sind fest ausgeschlossen, damit eine bereits
instrumentierte Funktion nicht dazu fuehrt, dass das Debug-Framework sich selbst
instrumentiert.
Bereits instrumentierte Funktionen werden uebersprungen (siehe [Idempotenz](#idempotenz)),
ihr Rumpf wird aber trotzdem nach weiteren, noch nicht instrumentierten Aufrufen
durchsucht - die Rekursion bricht dadurch nicht an einer schon bearbeiteten Stelle ab.
### --add-open
Fuegt in der angegebenen Methode (typischerweise ein `c:BEFEHL`-Kommando, das
einen ganzen Testlauf umspannt) ein:
```lisp
(dbgopen "<dbg-datei>" "<envvar>")
```
als erste Rumpf-Form, sowie
```lisp
(dbgclose)
```
vor **jedem** `(exit)`-Aufruf im Rumpf (auch verschachtelt) und zusaetzlich am
Ende des Rumpfs - ausser die letzte Rumpf-Form ist bereits selbst ein `(exit)`
(dann waere ein zweites `dbgclose` ohnehin unerreichbarer Code).
`--add-open DATEI METHODE` ist unabhaengig von `--method`/`--recursive` nutzbar
und mehrfach angebbar; alle drei Mechanismen lassen sich in einem Aufruf kombinieren.
## Schalter
| Schalter | Beschreibung |
|---|---|
| `datei` (Pflicht, Position 1) | Anker-`.lsp`-Datei; ihr Verzeichnis wird immer mitdurchsucht |
| `--method NAME` | Funktion mit `dbgf`/`dbg`/`dbgreturn` instrumentieren (mehrfach angebbar) |
| `--recursive` | Auch alle im Rumpf aufgerufenen projekteigenen Funktionen instrumentieren |
| `--search-dir DIR` | Weiteres Verzeichnis nach `.lsp`-Dateien durchsuchen (mehrfach angebbar). Default: `Lisp/` und das Verzeichnis von `datei` |
| `--max-depth N` | Maximale Rekursionstiefe fuer `--recursive` (Default: `3`) |
| `--exclude NAME` | Funktionsname von `--recursive` ausschliessen (mehrfach angebbar) |
| `--add-open DATEI METHODE` | `dbgopen`/`dbgclose` in `METHODE` (aus `DATEI`) einfuegen (mehrfach angebbar) |
| `--dbg-file NAME` | Dateiname fuer `(dbgopen ...)`. Default: aus dem `--add-open`-Methodennamen abgeleitet (`c:TEST_MUBEA` -> `test_mubea.dbg`) |
| `--dbg-envvar NAME` | Umgebungsvariable fuer `(dbgopen ...)` (Default: `DXFM_LOG`) |
| `--force` | Auch instrumentieren, wenn bereits `(dbgf ...)`/`(dbgopen ...)` vorhanden zu sein scheint |
| `--dry-run` | Nur ein Diff anzeigen, keine Dateien schreiben |
## Typischer Ablauf
1. **Immer zuerst `--dry-run`** laufen lassen und das Diff pruefen (mehrere Dateien
koennen betroffen sein, siehe `--recursive`).
2. Ohne `--dry-run` erneut aufrufen - die Dateien werden direkt (in-place) geschrieben.
3. In BricsCAD `(load ...)` neu laden bzw. den Testlauf starten.
4. Die `.dbg`-Datei (per `--add-open` geoeffnet, Pfad = `%DXFM_LOG%\<--dbg-file>`)
auswerten.
5. Da die Dateien in-place geschrieben werden und ueber Git versioniert sind: nach
dem Debuggen die Debug-Aufrufe entweder manuell entfernen oder die Datei(en)
per `git checkout -- <datei>` verwerfen (das Werkzeug selbst hat keinen
"--remove"-Schalter).
## Beispiele
Eine einzelne Funktion instrumentieren:
```
bin\dbg2lsp.bat tests\test_mubea.lsp --method mubea:build-separator-one --dry-run
```
Eine Funktion UND alles, was sie aufruft (bis Tiefe 3, Default):
```
bin\dbg2lsp.bat tests\test_mubea.lsp --method mubea:build-kreisel --recursive --dry-run
```
Mehrere Einstiegspunkte in einem Lauf, plus Oeffnen/Schliessen der Debug-Datei
im umgebenden Testbefehl - das entspricht genau der Instrumentierung, die fuer
den urspruenglichen Scanner-Bug in `TEST_MUBEA` von Hand gemacht wurde:
```
bin\dbg2lsp.bat tests\test_mubea.lsp ^
--method mubea:build-kreisel ^
--method mubea:build-vario-one ^
--method mubea:build-gf-one ^
--method mubea:build-separator-one ^
--recursive ^
--add-open tests\test_mubea.lsp c:TEST_MUBEA
```
Bestimmte generische Helfer von der Rekursion ausschliessen (z.B. um `ssg-start`/`ssg-end`
nicht mit anzufassen):
```
bin\dbg2lsp.bat tests\test_mubea.lsp --method mubea:build-kreisel --recursive ^
--exclude ssg-start --exclude ssg-end
```
## Funktionsweise / Aufloesung
- `datei` wird zuerst relativ zum aktuellen Arbeitsverzeichnis, sonst relativ zur
Projektwurzel (erkannt an `.git/` bzw. `Lisp/`, ausgehend von `datei` nach oben
gesucht) aufgeloest.
- Durchsucht werden: das Verzeichnis von `datei`, `Lisp/` (relativ zur Projektwurzel),
jedes `--search-dir` sowie das Verzeichnis jeder `--add-open`-Datei - jeweils
rekursiv nach `*.lsp`.
- Aus all diesen Dateien wird EIN Index `Funktionsname -> (defun ...)` aufgebaut
(case-insensitiv, wie AutoLISP-Symbole zur Laufzeit). `--method`/`--add-open`
muessen daher nicht in `datei` selbst stehen, sondern werden ueberall gefunden.
- Klammer-/String-/Kommentar-Erkennung ist zeichenweise implementiert (kein
vollstaendiger Lisp-Reader) - genuegt aber, um Top-Level-`(defun ...)`-Bloecke,
ihre Parameterliste und die letzte Rumpf-Form zuverlaessig zu erkennen, auch bei
mehrzeiligen Parameterlisten mit Locals nach `/`.
- Alle Aenderungen werden zunaechst als Liste von reinen Text-Einfuegungen
gesammelt (keine Loeschungen) und erst am Ende je Datei angewandt - Positionen
bleiben dadurch unabhaengig von der Bearbeitungsreihenfolge gueltig.
## Grenzen
- **Nur die letzte Rumpf-Form wird zu `dbgreturn`.** Fruehe `(exit)`-Ausstiege
MITTEN im Rumpf werden von `--method` nicht mit einem eigenen `dbgreturn`
versehen (nur `--add-open` behandelt `(exit)`-Stellen explizit, dort aber nur
mit `dbgclose`, nicht mit einem geloggten Rueckgabewert).
- **Kein "--remove".** Rueckbau erfolgt manuell oder per `git checkout -- <datei>`.
- **`--recursive` kann viele Dateien anfassen** - projekteigene Helfer wie
`ssg-start`/`ssg-val`/`ssg-attrib-merge` werden mitinstrumentiert, sobald sie im
Aufrufgraphen auftauchen. `--max-depth` und `--exclude` begrenzen das gezielt;
ohne `--dry-run`-Kontrolle vorher nicht blind auf grosse Funktionen mit hoher
`--max-depth` loslassen.
- **Mehrfache Definitionen desselben Namens** in unterschiedlichen Dateien: es
gewinnt der erste beim Durchsuchen gefundene (Dateireihenfolge nicht garantiert
sortiert-stabil ueber Verzeichnisgrenzen) - in dieser Codebasis kommt das
ueblicherweise nicht vor.
## Idempotenz
Vor dem Einfuegen prueft das Werkzeug, ob die erste Rumpf-Form bereits `(dbgf ...)`
(fuer `--method`) bzw. `(dbgopen ...)` (fuer `--add-open`) ist, und ueberspringt die
Funktion in dem Fall mit einer `[skip]`-Meldung. Mit `--force` wird trotzdem erneut
eingefuegt (fuehrt bei wiederholtem `--force`-Aufruf zu doppelten `dbgf`/`dbg`-Zeilen -
in dem Fall vorher besser die Datei zuruecksetzen).
-162
View File
@@ -35,18 +35,6 @@ Diese Werkzeuge ermöglichen die massenhafte Aufbereitung von einzelnen dxf Date
- [--number SIVASNR](#--number-sivasnr-1)
- [Uebersicht K-Zuordnung](#uebersicht-k-zuordnung)
- [Umgebungsvariablen](#umgebungsvariablen-1)
- [set\_attributs](#set_attributs)
- [Aufruf](#aufruf-2)
- [Datenquellen](#datenquellen-2)
- [Ablauf](#ablauf-2)
- [Konfiguration (attradd.cfg)](#konfiguration-attraddcfg)
- [Attribute Omniflo Kurve (Bogen)](#attribute-omniflo-kurve-bogen)
- [Attribute Omniflo Weiche](#attribute-omniflo-weiche)
- [CSV-Export-Felder (Merkmale)](#csv-export-felder-merkmale)
- [Schalter](#schalter-2)
- [--number SIVASNR / -n SIVASNR](#--number-sivasnr---n-sivasnr)
- [--dry-run / -d](#--dry-run---d)
- [Umgebungsvariablen](#umgebungsvariablen-2)
# set_einfuegepunkt
@@ -274,153 +262,3 @@ Nur die angegebene 9-stellige Sivasnr verarbeiten. Kombinierbar mit jedem Schalt
|---|---|
| `DXFM_DATA` | Pfad zu `data/` (JSON + DXF Quelldateien) |
| `DXFM_RESULTS` | Pfad zu `results/` (Ausgabe) |
---
# set_attributs
Fuegt Attribute (ATTDEF) zu allen Omniflo DXF-Dateien hinzu und verpackt die
gesamte Geometrie in eine benannte Blockdefinition. Die Attribut-Tags und deren
Werte werden ueber eine Konfigurationsdatei gesteuert.
**Voraussetzung:** Die Quelldateien in `data/omniflo/` sollten zuvor durch
`set_einfuegepkt.py` verarbeitet worden sein, damit `$INSBASE` korrekt gesetzt ist.
## Aufruf
```
python lib/set_attributs.py [--number SIVASNR] [--dry-run]
```
## Datenquellen
| Pfad | Inhalt |
|---|---|
| `cfg/attradd.cfg` | Attribut-Konfiguration (Tags und Quellfelder je Elementtyp) |
| `data/json/omniflo_boegen.json` | Liste aller Boegen mit Metadaten |
| `data/json/omniflo_weichen.json` | Liste aller Weichen mit Metadaten |
| `data/omniflo/*.dxf` | DXF-Quelldateien (Basis: Ausgabe von `set_einfuegepkt.py`) |
## Ablauf
1. Konfiguration aus `cfg/attradd.cfg` lesen
2. JSON-Daten laden und Lookup-Tabelle (Sivasnr -> Typ + Eintrag) erstellen
3. Fuer jede Sivasnr die DXF-Datei oeffnen, bestehende ATTDEFs entfernen
4. Neue ATTDEFs gemaess Config einfuegen (Layer `ATTRIB`, unterhalb der Geometrie)
5. Alle Entities (Geometrie + ATTDEFs) in eine Blockdefinition verschieben:
- Blockname = Sivasnummer (identisch mit dem Dateinamen ohne `.dxf`)
- Basispunkt der Blockdefinition = `$INSBASE` aus dem DXF-Header
6. Im Modelspace einen INSERT auf den neuen Block einfuegen, mit ATTRIB-Entities
befuellt aus den ATTDEF-Standardwerten (ermoeglicht Attributanzeige per Klick in BricsCAD)
7. Ergebnis nach `results/omniflo/` speichern
## Ausgabestruktur (DXF)
```
BLOCKS
BLOCK "<sivasnr>" (Basispunkt = $INSBASE)
<Geometrie-Entities>
ATTDEF BESCHR = "..."
ATTDEF ARTINR = "..."
...
ENDBLK
ENTITIES (Modelspace)
INSERT "<sivasnr>" at (0, 0)
ATTRIB BESCHR = "..."
ATTRIB ARTINR = "..."
...
SEQEND
```
Der INSERT im Modelspace traegt die konkreten Attributwerte und ist in BricsCAD
per Klick editierbar. Die Blockdefinition mit ATTDEFs dient als Vorlage fuer
den Block-Import via `import_element_as_block` (omniflo_utils.py).
## Konfiguration (attradd.cfg)
Die Config-Datei ist im INI-Format mit Abschnitten je Elementtyp.
Quellwerte koennen sein:
- **JSON-Feldname** (z.B. `ProfilTyp`) - Wert wird aus dem JSON-Eintrag gelesen
- **Fester Text** in Anfuehrungszeichen (z.B. `"Omniflo Kurve"`)
- **Platzhalter** `{sivasnr}` - wird durch die Sivasnr ersetzt
### Attribute Omniflo Kurve (Bogen)
| ATTDEF-Tag | Quelle | Beschreibung |
| --- | --- | --- |
| `BESCHR` | `ProfilTyp` | Profilbezeichnung aus JSON |
| `ARTINR` | `Sivasnr` | Sivas-Artikelnummer |
| `TEILEART` | `"Omniflo Kurve"` | Fester Typname |
| `RADIUS` | `Radius` | Kurvenradius in mm |
| `WINKEL` | `KurvenWinkel` | Kurvenwinkel in Grad |
| `SIVASNR_TEF` | `SivasnrTEF` | Sivas-Nr. des TEF-Antriebs (leer = kein Antrieb) |
| `LAYER` | *(aus [layer])* | Layer-Name gemaess Kategorisierung |
### Attribute Omniflo Weiche
| ATTDEF-Tag | Quelle | Beschreibung |
| --- | --- | --- |
| `BESCHR` | `ProfilTyp` | Profilbezeichnung aus JSON |
| `ARTINR` | `Sivasnr` | Sivas-Artikelnummer |
| `TEILEART` | `"Omniflo Weiche"` | Fester Typname |
| `WEICHENTYP` | `WeichenTyp` | Weichentyp (Einzelweiche, Doppelweiche, Dreiwegeweiche, ...) |
| `WINKEL` | `KurvenWinkel` | Kurvenwinkel in Grad |
| `RICHTUNG` | `KurvenRichtung` | Richtungskennung (1=Links, 2=Rechts, 3=Beide, 7=Dreiweg) |
| `SIVASNR_TEF` | `SivasnrTEF` | Sivas-Nr. des TEF-Antriebs (leer = kein Antrieb) |
| `LAYER` | *(aus [layer])* | Layer-Name gemaess Kategorisierung |
### CSV-Export-Felder (Merkmale)
Die Attribute werden beim CSV-Export (`export_csv.py`, aufgerufen ueber `c:EXPORTCSV`) wie folgt in CSV-Merkmale ueberfuehrt.
CSV-Format: `Elementnummer;TeileArt;TeileId;Bezeichnung;Anzahl;Merkmale`
**Omniflo Kurve:**
| Merkmal | Quelle | Typ |
| --- | --- | --- |
| `Kurvenwinkel` | JSON `KurvenWinkel` | float |
| `Radius` | JSON `Radius` | float |
| `Höhe` | Attribut `HOEHE` / Z-Koordinate | string |
| `Drehung` | Attribut `DREHUNG` / CAD-Rotation | float |
| `SivasNummer` | JSON `Sivasnr` | string |
**Omniflo Weiche:**
| Merkmal | Quelle | Typ |
| --- | --- | --- |
| `Weichentyp` | JSON `WeichenTyp` | string |
| `Richtung` | JSON `KurvenRichtung` | string |
| `Weichenwinkel` | JSON `KurvenWinkel` | float |
| `Höhe` | Attribut `HOEHE` / Z-Koordinate | string |
| `Drehung` | Attribut `DREHUNG` / CAD-Rotation | float |
| `Antrieb Kurve` | `SivasnrTEF` != null | bool |
| `SivasNummer` | JSON `Sivasnr` | string |
Höhe und Drehung werden beim Export selbst aus den Blockinformationen entnommen und dann ins json geschrieben.
| ATTDEF-Tag | Quelle | Beschreibung |
| --- | --- | --- |
| `HOEHE` | `"2000"` | Montagehoehe in mm (wird beim Export aus Z-Koordinate aktualisiert) |
| `DREHUNG` | `"0"` | Drehwinkel in Grad (wird beim Export aus CAD-Rotation aktualisiert) |
## Schalter
### --number SIVASNR / -n SIVASNR
Nur die angegebene Sivasnr verarbeiten.
### --dry-run / -d
Nur anzeigen welche Attribute gesetzt wuerden, ohne DXF-Dateien zu schreiben.
## Umgebungsvariablen
| Variable | Verwendung |
|---|---|
| `DXFM_DATA` | Pfad zu `data/` (JSON + DXF Quelldateien) |
| `DXFM_CFG` | Pfad zu `cfg/` (attradd.cfg) |
| `DXFM_RESULTS` | Pfad zu `results/` (Ausgabe nach `results/omniflo/`) |
Alle drei haben Fallback auf relative Pfade vom Projektverzeichnis.