als Quelltext-Distribution frei zur Verfügung. Weiterhin liegen dort statisch gebundene Binärversionen für Linux und SunOS bereit. Auf diese Weise lassen sich die Lizenzgebühren für OSF/Motif vermeiden. Damit ist EMA-XPS bei Verwendung des ebenfalls frei verfügbaren LISP- Interpreters CLISP komplett befreit von Lizenzgebühren.
Präsentation | vollfarbig | schwarz/weiß |
Sprache | deutsch | englisch |
Leistungsumfang | Vollversion | resourcenschonendere Laufzeitversion ohne Wissenseingabemöglichkeiten |
Tabelle S1: Ausprägungen von EMA-XPS
|
|
|
|
|
|
|
Tabelle S2: Hard- und Softwarevorraussetzungen von EMA-XPS
Bild S1: Stammbaum der UNIX-Betriebssystemvarianten
Bild S2: Mensch-Maschine-Kommunikation über eine Teletype
Bild S3: Ein grafischer Arbeitsplatz mit 2 Bildschirmen, Tastatur und Maus
Bild S4: Ablauf eines sequentiell arbeitenden Programms |
Bild S5: Ablauf einer ereignisorientiert arbeitenden Anwendung |
Bild S6: Entwicklung der Aufgabenverteilung in grafischen Client-Server-Anwendungen
Bild S7: Vernetzte grafische Arbeitsplätze unter dem X Window System
Bild S8: Kommunikation zwischen Clients und Xserver
Bild S9: Eventqueues
Bild S10: Ereignisabarbeitung bei den Xt-Intrinsics mittels Callbacks
Bild S11: Softwarearchitektur Xt-Intrinsics basierter Anwendungen
Bild S12: Erscheinungsbild der laboreigenen xgrf3-Liniengrafik
Bild S13: Interprozeßkommunikation bei der xgrf3-Liniengrafik
Bild S14: Mensch-Maschine-Kommunikation bei einem xterm
Es kann festgehalten werden, daß die Nachrüstung grafischer Frontends für bereits existierende Prozesse mittels Pseudo-Teletypes ermöglicht werden kann. Der Aufwand bei der Erstellung einer grafischen Anwendung reduziert sich hierbei auf die Oberflächengestaltung. Eine komplette Reimplementierung des Leistungsumfangs kann unterbleiben. Die Funktion isatty(), die von derartigen existierenden Programmen oft genutzt wird, um die Notwendigkeit interaktiver Arbeitsweise festzustellen, kann "überlistet" werden. Bei derartigen Lösungen handelt es sich - wie bei der Liniengrafik xgrf3 - um Zwei-Prozeß-Lösungen. |
Durch die Zwei-Prozeß-Lösung kann die sequentielle Programmabarbeitung der Expertensystemschale aufrechterhalten werden. |
Die angestrebte Zwei-Prozeß-Lösung benötigt ein preemptives Multitasking-Betriebssystem, das Pseudo-Teletypes zur Verfügung stellt. |
Das Betriebssystem UNIX stellt alle genannten
Voraussetzungen bereit. Es ist für eine große Zahl
unterschiedlicher Hardwareplattformen einschließlich PCs
verfügbar. Die Vorgabe, eine auf möglichst vielen
Rechnerumgebungen verfügbare Software zu erstellen, ist
also ausreichend erfüllt.
Bild S15: Die hybride Architektur von Babylon-2
C-Seite Name der Pipe |
Richtung Handler |
LISP-Seite Name des Stroms |
Verwendung |
---|---|---|---|
Toplevel-Pipe | <==> (1) |
*terminal-io* | Standardein-/ausgabe über den Debugger PAD |
Graphic-Pipe | <==> (2) |
*graphic-stream* | Anweisungen zur Erstellung von Popupdialogen |
Dialog-Pipe | <==> (3) |
*dialog-stream* | Sitzungs PAD |
Explain-Pipe | <== (3) |
*explain-stream* | PAD für Erklärungen |
RuleT-Pipe | <== (3) |
*rule-stream* | PAD für die Ausgabe des Regel-Trace |
PrologT-Pipe | <== (3) |
*prolog-stream* | PAD für die Ausgabe des Prolog-Trace |
ConsatT-Pipe | <== (3) |
*consat-stream* | PAD für die Ausgabe des Consat-Trace |
SystemT-Pipe | <== (3) |
*system-stream* | PAD für die Ausgabe des System-Trace |
Tabelle S3: Interprozeßkommunikationskanäle von EMA-XPS v1
Bild S16: Die Zwei-Prozeß-Lösung von EMA-XPS mit ihren unterschiedlichen Programmiermodellen
Bild S17: Lesen und Beschreiben der Pipes
über den *graphic-stream* gesandt. Der C-Prozeß erzeugt einen geeigneten Popup-dialog mit den notwendigen Texteinträgen, die er der Protokollsequenz entnommen hat. LISP wartet mittels read auf eine geeignete Antwort. Nachdem der Benutzer seine Eingaben abgeschlossen hat, schließt der Grafikserver den Dialog und sendet eine Antwortsequenz in die Graphic-Pipe.
Bild S18: Hauptmenü von EMA-XPS v1 |
Bild S19: LISP-Debugger PAD am Ende der Bootphase |
Bild S20: Flußlaufplan des LISP-Toplevelloops
*evalhook* | alternative Evaluations-Funktion |
*applyhook* | beeinflußt die Anbindung der Argumentliste an eine Funktion |
*macroexpand-hook* | anderes Vorgehen bei der Makro-Expansion |
*debugger-hook* | eine Alternative zum Einsprung in den Debugger (erst in CLtL2 festgeschrieben, von etlichen CLtL1-Interpretern aber bereits als Erweiterung angeboten) |
Tabelle S4: Möglichkeiten der Beeinflussung des Toplevelloops
Die Graphic-Pipe kann dann auf die Standardausgabe gelegt
werden, wenn das Grafik-Protokoll als ununterbrechbar
definiert wird. Während der Initialisierungsphase sendet
LISP nur Standardausgaben. Sobald eine Grafik-Nachricht
zu übertragen ist, wird die Protokolleröffnungssequenz
geschrieben. Der modifizierte toplevelPipeInputHandler
erkennt, daß eine Nachricht folgt und schreibt die
empfangenen Zeichen nicht mehr in den Debugger PAD,
sondern leitet bis zur Protokollendesequenz alle Zeichen
der grafischen Auswertung zu.
Das Protokoll kommt außer Tritt, wenn zwischen Eröffnungs- und Endesequenz protokollfremde (Standard-)Ausgaben geschrieben werden. |
Durch Einbringen der C-seitigen Leistungserweiterung, die Eingabewarteschlange für LISP-Befehle umsortieren zu können, kann trotz einer Beschränkung auf einen einzigen LISP-seitigen Lesekanal die Funktionsfähigkeit aufrecht erhalten werden. |
In der derzeitigen Implementierung ist der Kanal 010 gleichbedeutend ist mit der Aufforderung an die C-Seite, einen Informationsdialog mit dem Text "Zugriff verweigert!" und einem Bestätigungs-Knopf zu erstellen (Bild S21) und LISP bis zur Quittierung durch den Benutzer warten zu lassen.
Bild S21: Ein Informationsdialog von EMA-XPS v2
Jede Grafikprotokollsequenz beginnt also mit einer Kanalnummer größer oder gleich 10 und endet mit einer Nummer kleiner 10. Die Protokolldisziplin verlangt, daß dazwischen keine protokollfremden Zeichen übertragen werden dürfen. Für jede verwendete Kanalnummer ist eine Handlerroutine zu registrieren, die die notwendigen Aktionen durchführt. |
Das Funktionieren dieses Konzepts setzt eine C-seitige Kenntnis des aktuellen Zustands des LISP-Interpreters voraus. Eine geeignete Beobachtung ist zu ermöglichen. Zustandswechsel sind daher C zu signalisieren. |
);let ) |
Bild S22: Toplevel Evalhook-Handler von EMA-XPS
EMA-XPS v2.1 setzt die Verwendung eines LISP-Interpreters voraus, der CLtL1-konform ist und darüberhinaus die CLtL2- Erweiterung des debuggerhook bereitstellt. |
Als grafische Rückmeldung des aktuellen Zustands der LISP- Welt wird immer dann, wenn der Interpreter nicht RDY ist, die Form des Mauszeigers von dem üblichen Pfeil in eine Uhr verwandelt. |
Bild S23: Zustandsmaschine als Beobachter des LISP-Prozesses
unter babylon-3 dagegen eher wie Funktionen:
Um in den Körpern von Regeln, Constraints und dergleichen nicht nach Behavioraufrufen suchen zu müssen, um sie mit Startern zu versehen, werden für jedes Behavior Makros folgender Form definiert:
(defmacro nachricht (instanz &rest args)
|
babylon-3 verwendet jeden Namen nur einmal je Wissensbasis. Doppeldeutigkeiten sind damit ausgeschlossen. Wenn zwei babylon-3 Wissensbasen gleichnamige Behaviors haben, werden die erzeugten Makros gleiche Namen und gleiche Körper besitzen. Die Wirkung des in Kapitel 4.8.1 aufgeführten Problems des Überschreibens beim Laden der Wissensbasen ist damit aufgehoben.
Bild S24: Protokollausgaben beim Importieren von babylon-3 Wissensbasen