von Steve Johnson
BLADE ist ein herausragendes neues Feature in BricsCAD V18.2. Es ist das "BricsCAD LISP Advanced Development Environment", die Visual LISP IDE in BricsCAD.
Bricsys hat nicht nur mit Autodesk gleichgezogen, sondern bietet eine Vielzahl an erweiterter Funktionlität, welche der Autodesk VLIDE (aus dem Jahre 1999) so weit voraus ist, daß es unwahrscheinlich ist, dass VLIDE dies jemals aufholen kann - und dennoch bleibt BLADE in hohem Maße kompatibel.
Ich hatte die Gelegenheit, diese IDE in der (zu diesem Zeitpunkt noch unbenannten) Vorab-Version zu sehen, als ich an der Bricsys 2017 Konferenz in Paris teilnahm. Ich war überrascht und erfreut, die IDE Funktionaliität zu sehen, vorgeführt durch ihren Autor, Torsten Moses. Kürzlich hatte ich die Gelegenheit, mit Torsten ein Interview zu führen.
Torsten, ich verstehe, daß es schwierig war, eine LISP IDE für BricsCAD zu erstellen, wegen der spezifischen Weise, in welcher BricsCAD LISP arbeitet. Kannst Du dies etwas erklären ?
BricsCAD LISP verwendet die "OpenLisp Core Engine" des französischen Entwicklers Christian Jullien; dies ist die einzige Lisp Engine, welche aktuell immer noch weiter entwickelt wird - alle sonstigen Lisp Systeme haben ihre Entwicklung (meist unvollendet !) in der Mitte der 90er Jahre eingestellt.
OpenLisp ist eine hochmoderne Implementierung, in keiner Weise mehr vergleichbar mit jenem (einfachen) XLisp Dialekt, welcher die Grundlage von AutoCAD AutoLISP ist; OpenLisp bietet u.a. objektorientierte Schnittstellen und Programmierung, NamesSpaces, und andere Konzepte, welche man sonst nur aus modernen Sprachen kennt (z.B. C++). Aus diesem Grund ist die interne Darstellung/Speicherung der "Lisp Expressions" deutlich verschieden von der textuellen Darstellung des Lisp Programmcodes in der Lisp Datei bzw. in einem Editor.
Dies bedeutet, daß der AutoLISP code, welchen ich schreibe, nicht der Code ist, wie ihn BricsCAD ausführt ?
Stimmt - eine Anzahl typischer AutoLISP Anweisungen werden in einer speziellen Emulation ausgeführt, was den Unterschied zwischen der internen und externen Darstellung bzw. Speicherung noch vegrößert. Es war eine enorme Herausforderung, die interne Ausführung des LISP Codes (OpenLisp Expressions) mit der textuellen Darstellung in einem Editor zu synchronisieren, um eine Debugging-Funktionalität überhaupt sinnvoll zu ermöglichen.
Neben diesen rein technischen Problemen, welche bis dato als praktisch nahezu unlösbar erschienen, war es aber auch der zu erwartende enorme Aufwand, eine vollständige, moderne und effektive GUI zu implementieren - nicht nur einen Editor, sondern die gesamte GUI inklusive Debugger, Projekt-Verwaltung, Outlining-Funktionalität, und einges mehr.
"Es wäre wohl eine herbe Enttäuschung, ja geradezu eine Blamage gewesen, hätten wir eine LISP IDE auf dem Niveau der AutoCAD VLIDE angeboten; jene war genial zu ihrer Zeit, aber nun ist es fast 20 Jahre später."
Die Idee einer LISP IDE für BricsCAD war so voller Probleme, daß wir es für lange Zeit "auf Eis" gelegt hatten ...
Wie wurden die genannten Schwierigkeiten letztlich überwunden ?
Zunächst war es der reine Zufall. [lacht], Ich (wieder-)entdeckte ein kleines, verstecktes Detail in OpenLisp - jedem Lisp Symbol (und auch Lisp Code ist eine Art "anonymes Symbol") kann eine unbegrenzte Anzahl zusätzlicher Lisp-Daten angehängt werden, sehr ähnlich den XData, welche jedem Datenbank-Objekt in der DWG Datei zugeordnet weden können.
Ich kenne dieses Detail seit vielen Jahren, kam aber mangels anderweitigem Bedarfs an dieser sehr spezifischen Funktionalität nie auf die Idee, dies für die bidirektionale Verbbindung zwischen OpenLisp Core und einem externen Editor zu nutzen. Ein paar weitergehende Tests haben dann schnell bestätigt, daß dieser Mechanismus sehr geeignet ist, um einen Debugger zu implementieren (der Debugger ist sozusagen die Verbindung zwischen Editor und OpenLisp Core).
Ein weiterer Zufall kam (zeitgleich) ins Spiel - ich fand, daß WxWidgets (unser Cross-Platform Toolset, nicht nur für GUI) bereits den berühmten und weltweit genutzten "Scintilla" Editor integriert, und programmiertechnische Unterstützung auf mehreren Ebenen beinhaltet (einen reinen Code-Wrapper für den Scintilla Core Editor, und eine höhere, WxWidgets-konforme API), und somit perfekt & nahtlos in BricsCAD nutzbar sein müßte.
Dennoch stellt der genannte WxWidgets Support für "Scintilla" nur die Programmier-Schnittstelle dar - keinen Editor, und keine erweiterte GUI.
Schließlich fand ich dann (der nächste glückliche Zufall) den "wxStEdit" genannten Editor - eine äußerst effektive Implementierung eines Editor + GUI, basierend auf der beschrieben WxWidgets "Scintilla" Schnittstelle - dies inklusive Quellcode, und unter OpenSource / WxWidgets Lizenz, welche es uns erlaubt, den OpenSource Code in einem kommerziellen Programm zu nutzen.
Weitere Vorab-Tests haben dann bestätigt, daß diese wxStEdit/WxWidgets/Scintilla Implementierung für BLADE sehr gut nutzbar und erweiterbar ist. Die Entwicklung des wxStEdit war etwa 2008 abgeschlossen, basierend auf WxWidgets v2.8 - und rund 10 Jahre später immer noch kompatibel mit WxWidgets v3.0. Im Laufe der BLADE Entwicklungen wurden aber eine Vielzahl an Defekten, Bugs und "Macken" in Scintilla, WxWidgets, und wxStEdit gefunden und bereinigt.
Es war also diese Verkettung interessanter Zufälle, welche schließlich beide Flügel eines sehr großen Tores öffneten - bildlich gesprochen.
Ich habe schon früher dokumentiert, daß BricsCAD's LISP Engine den AutoLISP und VisualLISP Code mehrfach schneller ausführt als AutoCAD. Wie beeinflußt die neue Technologie diese Performance ?
Alle technischen Details in der BLADE-Implementierung beeinflussen die normale Ausführung des LISP Codes, außerhalb von Editor und Debugger, praktisch gar nicht. Die Verbindung von BLADE's Editor und Debugger basiert auf einigen wenigen "Callbacks" (oder auch "Hooks", oder "Reaktoren" genannt), welche nahezu keinen Performance-Einfluss haben; durch diese Technik der Einbinduung ist auch das Risiko negativer Nebeneffekte minimiert.
"Die BLADE Implementierung ist sehr sicher, und die LISP-Performance bleibt weiterhin sehr hoch in der normalen Anwendung."
Für den Debugger und die Synchronisierung (zwischen Editor/Debugger und OpenLisp Core) kommt ausschließlich eigene Technik zur Anwendung, optimiert für beste Performance (auch im Debugger), und minimalen System & LISP Speicher-Verbrauch.
Im Rahmen der Entwicklung des Debuggers, und der Synchronisierung zwischen interner und externer Lisp Code Darstellung, wurden die meisten der zuvor genannten Emulationen entfernt, und als native OpenLisp Kernfunktionen eingebaut. Dies hat den netten Nebeneffekt, daß die (repeat), (foreach) und (vlax-for) Funktionen nun ca. 5x schneller arbeiten (im Aufbau und der Abarbeitung des Schleifen-Kopfes). Insofern hat BLADE den LISP Code nicht langsamer, sondern sogar schneller gemacht.
Werden die BricsCAD Versionen für Mac und Linux die BLADE IDE auch erhalten?
Ja, die BLADE Implementierung ist 100% kompatibel, basierend auf der ausschließlichen Verwendung von WxWidgets, und eigener Technik. Es gibt im Implementierungs-Code keinerlei Windows-, oder Linux-, oder Mac-spezifischen Code. Ich habe BLADE selbst unter meinem BricsCAD Linux getestet.
Kannst Du ein einfaches Beispiel für den Ablauf einer typischen Debug-Session geben?
Zuerst einmal brauchen keine Lisp-Datei(en) in BricsCAD "vorgeladen" zu werden (können aber); Lisp-Code, welcher ausserhalb des Debuggers geladen wird, kann nicht für das Debuggen verwendet werden, ist aber normal abarbeitbar, und verhält sich dann wie "native AutoLISP" Funktionen. Die spezielle, bi-direktionale Verbindung zwischen dem Lisp-Code im Editor/Debugger und der zugehörigen OpenLisp-internen Darstellung wird nur aufgebaut, wenn die Lisp-Datei über den Debugger geladen wird.
Als Nächstes kann nun ein beliebiges FAS oder VLX Projekt, oder eine "Named Session", oder auch nur die benötigten Lisp-Dateien, im Editor geöffnet werden, welche(s) man zum Debuggen verwenden möchte.
"Mit 'Start Debugging' aus dem Menü oder von der Toolbar, oder auch mit der F8-Taste wird dann der 'Debug-Modus' gestartet - es erscheint die spezielle Debug-Toolbar. Man kann 'AutoBreak' aktivieren, welches automatisch beim ersten ausführbaren Lisp-Code einen Halt bewirkt, und/oder die gewünschten Code- oder Daten-BreakPoints können gesetzt werden."
Nun kann die gewünschte Lisp-Datei geladen werden - entweder direkt in BricsCAD mit den üblichen Methoden, oder über die "LISP Console", oder am einfachsten mittels des "Load" Buttons in der Debug-Toolbar. Der so geladene Lisp-Code ist nun debugfähig, und man sieht den/die geladenen Lisp-Dateien und die enthaltenen Funktionen in den 2 rechten Tab-Fenstern (im Debug-Panel am unteren Rand). Wird nun einer der eingestellten Code- oder Daten-BreakPoints (bzw. der automatische Halt am ersten ausführbaren Code mit 'AutoBreak'), werden alle verfügbaren Step-Modi in der Debug-Toolbar aktiviert, es sind alle üblichen Step-Modi vorhanden, effektiv mehr als in der AutoCAD VLIDE. Man kann Lisp-Variablen als "Watches" definieren, und optional auch als "Daten-BreakPoint" setzen - im letzteren Fall wird die Lisp-Code Ausführung angehalten, wenn sich der Datenwert bzw. Datentyp ändert.
Teil 2 des Interviews folgt in wenigen Tagen. Torsten Moses administriert seine eigene Gruppe in der BricsCAD Deutschland Community und ist darüber auch erreichbar. Etwaige Fragen können gerne im LiveFeed der Gruppe gestellt werden und werden dort von Herrn Moses auch beantwortet. Die Gruppe von Torsten Moses finden Sie hier, Sie müssen registriert und eingeloggt sein, um die Inhalte lesen zu können.
Dieses Interview wurde im Original ursprünglich in zwei Teilen auf Steve's Blog Nauseam Site veröffentlicht.