APL

Alles hat seine Grenzen, so auch der APL2 Object Editor.

Denn sehr große Funktionen können schon mal Probleme beim Editieren bereiten. Ich meine damit nicht, dass man sich schlecht in ihnen orientieren kann, lange nach zu ändernden Stellen suchen und sehr viel vor und zurück blättern muss. Die Probleme können rein technischer Art sein:

Es fängt schon damit an, dass Doppelklick auf den Namen der Funktion diese nicht in den APL2 Object Editor lädt. Immerhin verrät der Session Manager in der Statusleiste, was ihn stört: "System Limit - Interface Capacitiy". Alles klar?

Es kann auch passieren, dass, nachdem die Funktion klaglos in der Object Editor geladen wurde, vorgenommene Änderungen an der Funktion nicht gespeichert werden können. Auch der Editor versucht uns in der Statusleiste zu erklären, was ihm fehlt: "System Error - Shared Memory Shortage". Kling gefährlich, ist es aber nicht.

Bevor es allzu abstrakt wird, hier ein Beispiel aus meinem wirklichen Leben:

Ein weiteres kaum genutztes Systemkommando war und ist )QUOTA. Ich habe es auf dem Host das letzte mal vor einigen Jahren benutzt und mehrfach versucht, es unter Windows auszuführen. Zu blöd, denn Workstation APL2 kennt dieses Kommando nicht und wird es wahrscheinlich auch nicht kennen lernen.

)QUOTA gibt manchmal hilfreiche Größenangaben zum Workspace, zur APL2-Bibliothek und zum Shared Variable Interface. Diese Angaben machen aber teilweise nur in der Host-Umgebung Sinn. So müssten in Workstation-Umgebungen der Werte für die Größe der privaten APL2-Bibliothek und der dort noch verfügbare Speicherplatz uminterpretiert werden.

Auf der Workstation kann ich anders als auf dem Host die Workspace-Größe "dynamisch" vorgeben: starte bei einer minimalen Vorgabe, falls eine Anwendung mehr Platz benötigt, erhöhe sie um schrittweise um eine bestimmte Größe solange bis die Grenze des Erträglichen erreicht ist.

Leider ist es nur schwer herauszufinden, wie viel Platz APL2 in einer konkreten Situation für sich beansprucht. Aus der Sicht der Entwicklers von APL-Systemen scheint eine solche Information sinnlos oder gar schwer ermittelbar zu sein, aber ich habe sie schon häufiger vermisst.

Apropos "vermissen": Wo finde ich im Workstation-APL2 die )QUOTA-Angaben zur maximalen Anzahl gleichzeitig aktiver Shared Variables und zur Größe des "Shared Storage"?

Ich glaube, )CHECK WS gehört zu den kaum bekannten und daher wenig genutzten Systemkommandos. Ich gebe gerne zu, dass ich es selbst lange nicht mehr verwendet habe.

Warum auch? Denn )CHECK WS wird automatisch beim Laden und Speichern eines Workspaces ausgeführt. Ist was faul im WS, so gibt es Meldungen wie in "Schuld war nur die Platte" beschrieben. Wer wie ich häufig eine Workspace während der Entwicklung und des Testens speichert bekommt also )CHECK WS geschenkt.

Nun gibt es aber noch eine Variante von )CHECK WS, die ich total vergessen hatte:

)CHECK WS [ON|OFF]

Man muss schon recht verzweifelt sein, um diesen Schalter umzulegen. Denn danach wird nach jeder Ausführung einer APL2-Grundfunktion ("primitive function") der Workspace ausgiebig geprüft. Bei größeren Anwendungen kann man ruhig ein Tasse Kaffee trinken gehen.

Die hiernach angesagte Tuning-Maßnahme wäre dann )CHECK WS OFF. Ich habe selten mit so wenig Aufwand eine Anwendung um das Vielfache beschleunigt. Mit )LOAD und )CLEAR erzielt man übrigens in diesem Falle das gleiche Ergebnis: Diese Kommandos setzen einen gesetzten )CHECK WS Schalter wieder zurück.

Dies alle und noch viel mehr kann im APL Language Reference (S.418) nachgelesen werden.

Wer kennt ihn nicht, den SYSTEM ERROR/CLEAR WS. APL2 ist auch unter Windows inzwischen ein sehr stabiles System, aber manchmal zerreißt es auch das beste System. Ich denke, häufig ist es Windoof, das den Speicher zerbröselt, so dass die Pointer-Verwaltung im APL2 nicht mehr stimmt.

Aber es muss nicht immer der übliche Verdächtige sein.

Ich habe vor einigen Wochen einen CONTINUE geschickt bekommen, der nach dem Laden folgende Meldung ausgab:

Checkws: mentry does not point back, ri = 0x350d0

Auf dem Rechner des Entwicklers gab es kurz vor dem SYSTEM ERROR/CLEAR WS eine schier unendlich lange Liste (immerhin ca. 1000 Zeilen) mit solchen Ausgaben und darauf folgend noch Meldungen wie

Checkws: points to mentry with different ri, ri = 0xdbda

Zu guter Letzt beklagt sich Checkws noch über ein "negative-length object".

Das erste, was ich in einem solchen Fall mache, ist ein WS-Reorg: )CLEAR, )COPY und )SAVE. Das räumt auf und reduziert den belegten Speicher. Dies wollte aber hier nicht die erwartete Heilung bringen. In nerviger Regelmäßigkeit stürzte das APL2 per SYSTEM ERROR ab.

Der Hinweis zur Lösung war dann letztendlich, dass obige Probleme auf anderen Rechnern nicht auftraten. Schuld war wohl die Festplatte. Denn nachdem diese "repariert" wurde, tritt der SYSTEM ERROR nicht mehr auf.

In "Was gibt's Neues in CSD8" habe ich folgende Erweiterung vergessen:

- Windows XP themes will be recognized and used in all APL2 GUI windows.

Tatsächlich habe ich das nicht übersehen oder gar vergessen, nein, viel schlimmer, ich habe die Weitergabe dieser Info unterdrückt. Denn bis heute wusste ich nicht, was das konkret bedeutet und wie ich eine Änderung erfahrbar machen kann.

Jetzt habe ich den Unterschied sichtbar machen können:

Alles klar?

Windows XP Themes können in den "Eigenschaften von Anzeige" (Microsoft deutsch) aktiviert, geändert und gespeichert werden.

Mit dieser Erweiterung sehen APL2 GUI "besser" aus. Das liegt sicher daran, dass sie sich besser in das "look" meiner anderen Desktop-Anwendungen einfügen.

Eine absolut sinnvolle Erweiterung und Schande über mein Haupt, dass ich sie vorher nicht auch nur eines Wortes gewürdigt habe.

Vista? Wer oder was ist Vista?

Das könnte mir ja eigentlich egal sein. Wenn die nächste Version von Windows gemeint sein sollte, wird es ja wohl noch etwas dauern, bis MS damit meint fertig zu sein. Dann beginnt erst der weltweite kostenpflichtige Testphase durch die Early Adaptors. Armes Völkchen!

Selbst das danach erscheinende SP1 wird mich dazu verleiten nach Vista upzugraden. Warum auch? Ich habe mich noch nie von SPs überzeugen lassen.

Aber man sollte stets mit der ordnungsgemäßen Planung deutscher Unternehmen rechnen. Es gibt doch tatsächlich Unternehmen, die Vista nach Verfügbarkeit ausrollen wollen, und das muss geplant sein. Das wirft dann folgende Frage auf:

Welche APL+Win Version läuft unter Vista.

Eine Frage an den Hersteller, hier zusammengefasst und ohne Gewähr die Antwort:

- die aktuelle Version 6.0 wird sicher unter Vista laufen
- Version 5.2 wurde schon frühzeitig unter Longhorn getestet
- bei Version 5.0 könnte man noch optimistisch sein

Alle Versionen vor 5.0 liegen mehr als 3 Jahre zurück, also teilweise noch vor XP. So gab es z.B. Probleme ⎕wi in APL+Win 3.0 unter 2000 und XP.

Ordnungsgemäß planende deutsche Unternehmen sollten also sehr alte APL+Win Versionen upgraden.

Das waren die guten Nachrichten über "IN". Kann ich also meine korrigierte Variante von "IN" durch die offizielle Version ersetzen? Das wäre erstrebenswert, geht aber nicht. Denn ich habe noch zwei weitere Dinge "verbessert" - verbessert im Sinne der Verwendung von "IN" in meinem APL-Workspace Crawler.

Das INen von großen geschachtelten Variablen kann sehr lange dauern und während dieser Zeit die kompletten CPU-Ressourcen in Anspruch nehmen. Dies kann nicht direkt IN oder )IN angelastet werden, denn der eigentliche Übeltäter ist ⎕TF.

Hierzu ein Beispiel: Auf meinem neuen 2 GHz Rechner dauert das Inen einer 10553x24-Matrix der Tiefe 2 ca. 20 Minuten. Die Größe der Variable ist, gemessen mit "4 ⎕AT", 9.117.824 bzw. 1.744.766. Die Größe der ATF-Datei, die ausschließlich die Variablen enthält ist, ca. 2MB.

Für den meinen Crawler, der sowieso nur nach Funktionen und Operatoren sucht, war das pure Zeit- und Ressourcenverschwendung. Ich habe mir daher die Definition von IN vorgenommen und entsprechend geändert: Hast du gerade eine Variable zur Bearbeitung vor dir, dann gehe zum nächsten Objekt. Einfach und effizient!

Wäre das nicht auch ein Feature für die offizielle Version von "IN". Auch dem APL2 Library Manager würde es gut zu Gesicht stehen: Der Anwender wird vor dem Einlesen komplexer APL2-Variablen aus ATF-Dateien erst mal gefragt, ob er sie wirklich sehen will - oder ähnlich.

Es gibt schon nette Zufälle. Da habe ich mich in einem Vortrag darüber beklagt, dass die externe Funktion "IN" ('FILE' 11 ⎕NA) nicht kompatibel zum Kommando )IN ist. Und keine Stunde später sind zumindest zwei meiner Vorschläge bereits umgesetzt.

Naja, nicht mal ein APL-Entwicklungsteam arbeitet so schnell, obwohl die sonst schon sehr schnell reagieren.

Die wahre Geschichte ist folgende: Ich war eben nicht der Einzige, der Stress mit "IN" hatte. David bekam die gleichen Probleme, als er "IN" für seinen Library Manager einsetzte. Als Entwickler war es für ihn ein leichtes, eine verbesserte Version von "IN" zu erstellen oder anzufordern. Ich habe nur meine eigene, inoffizielle korrigierte Variante.

Diese Änderungen blieben aber undokumentiert. In der Liste der "Enhancements Added" zur CSD8 fehlen entsprechende Einträge, der User's Guide ist hier - "Supplied Workspaces/FILE Workspace/Transfer Group" - ohne Änderung.

Und das ist neu:

IN '99 ATFNAME'
IN '''e:\temp temp\name.atf'''

Bis zur CSD8 haben die Leerstellen "IN" zur vorzeitigen Aufgabe gezwungen - zur erkennen am Ergebnis 0.

Alles Jahre wieder gibt es eine Neue Version von APL+Win. Vor zwei Jahren war es Version 5.0, letztes Jahr 5.2 und nun 6.0. Nicht so richtig konsequent, was die Zählweise betrifft. Aber egal.

Das Highlight der 6.0 ist offensichtlich das neue, kolossale Dateisystem. Von der Struktur her arbeitet das "Colossal Filesystem" genauso wie das allseits bekannte und beliebte Komponenten-Dateisystem, nur viel schneller. Ich habe im Januar Messungen gesehen, die in Extrem-Situationen eine 1000fache Verbesserung brachten.

So oder auch weniger, sicher ist, es ist auf jeden Fall tierisch schnell.

Mit den CFS fällt auch die 2GB-Grenze für die Größe der Datei. Das war auch inzwischen nötig. Wer also viel mit Komponenten-Dateisystemen arbeitet, wird mit neuen System viel Freude haben.

Interessant ist auch die TRY-CATCH-Kontrollstruktur. Java-Entwicklern wohl bekannt, kann sie zur besseren Strukturierung von APL-Code führen. Auf jeden Fall macht sie das Error-Handling explizierter als es mit ⎕elx möglich ist.

... in CSD8? Kurz geantwortet:

Den APL2 Library Manager:
Ein Werkzeug zum durchforsten von APL2 Workspaces in allen drei Dateiformaten: .APL, .ATF und .ANS. Der APL2LM erspart es mir z.B. das Laden eines Arbeitsbereiches, um dort etwas zu suchen oder anzusehen. Es sieht aus, als ob der APL2LM ein sehr nützliches Werkzeug werden könnte!

Über eine weitere Neuerung habe ich bereits geschrieben: "Calls to APL2", das Arbeiten mit Slave-Interpretern direkt aus einer APL2 Sitzung heraus. Dazu wurden gleich zwei Dinge zum APL2 System hinzugefügt, die externe Funktion APL2PIA und der Hilfsprozessor 200. Der APL2 Library Manager macht reichlich Gebrauch von APL2PIA.

Es gibt noch viele "kleinere" Erweiterungen:

Montag, kurz vor Mitternacht, habe ich eine meiner Regeln verletzt und wäre auch fast bestraft worden. "Don't change a running system" vor einer Präsentation. Aber meine Neugierde überwog, und ich installierte kurzerhand die CSD8. Um sicher zu gehen, testete ich nochmals die Anwendung, über die ich am Dienstag reden wollte. Siegessicher starte ich sie, machte die nötigen Eingaben und ... nichts passierte. Das war nicht ok, irgendwas war falsch.

Kurzum: der Grund war ein SQL0818N "Ein Zeitmarkenkonflikt ist aufgetreten". Warum, weshalb? Dienstags um 0 Uhr hatte ich keine Ahnung. Offensichlich eine Verstimmung zwischen APL2 und DB2, denn der Zugriff auf die betroffene DB2-Tabelle funktionierte klaglos im DB2-Befehlszeilenprozessor.

Trotz allen Mutes, bin ich doch immer noch einigermaßen vorsichtig. Ich hatte als Netz und doppelten Boden die CSD7 noch auf der Platte. Das bin-Verzeichnis zurück kopiert, und alles war wieder gut.

Die Lösung des Rätsels gab's am kommenden morgen. Nancy, die Entwicklerin des AP127 ("eine 27-jährige entwickelte diesen AP") hatte dieses Problem schon am Freitag gesehen. Sie schlug gleich zwei Lösungen vor:

1. den AP127 neu binden
2. den AP127 der CSD7 in das aktuelle bin-Verzeichnis zurück kopieren.

Nächstes Jahr jährt sich zum fünfundzwanzigsten mal meine erste Berührung mit APL, dieser fantastischen Sprache. Nachdem ich mich die Jahre vorher mit Cobol, Assembler, Fortran und ähnlichen unangenehmen Dingen auf Computern herumgeschlagen habe, war dieser Erstkontakt der Beginn einer wunderschönen Beziehung mit der Spezies Computer.

Naja, Scherz beiseite. In 25 Jahren sammelt sich so einiges an Arbeitsbereichen, Funktionen, Operatoren und Variablen. Da verliert man schon mal den Überblick.

Wie oft habe ich Workspaces nach einer Funktion durchsucht, von der ich wusste, dass sie existiert, aber ich nicht wusste, wo. Auch kam es vor, dass ich mir absolut sicher war, vor einiger Zeit einen Workspace erstellt zu haben, aber ich wusste nicht mehr, in welchem Verzeichnis ich ihn abgelegt hatte

Über die Jahre haben sich auf meinem Rechner viele Verzeichnisse mit APL-Arbeitsbereichen angesammelt - Ordnung muss sein - und noch mehr Arbeitsbereiche und noch viel mehr Funktionen und Operatoren.

Es kann schon sehr lästig sein und viel Zeit kosten, eine Funktionen in ihrer aktuellsten Version in mehreren Workspaces in verschiedenen Verzeichnissen suchen zu müssen: Workspace laden, Funktion suchen, öffnen, inspizieren, Fix-Zeitpunkt merken, nächsten Workspace laden, Funktion suchen, ...

Gemäß den Datumsangaben in meinen Java-Klassen oder den APL2-Funktionen, die auf diese Klassen zugreifen, ist es nun zwei Jahre her ist, dass ich mich mit Java beschäftigt habe. Nicht, weil ich Java so toll finde, sondern um die Schnittstelle vom und zum APL2 zu nutzen. Das hat auch einiges Beständiges gebracht, Funktionen, die ich seitdem regelmäßig genutzt habe.

Java Klassen entwickelt habe ich seitdem nicht mehr. Damit ich es in zwei Jahren leichter habe, wenn ich mich evtl. wieder nach längerer Pause in Java einarbeiten muss, nutze ich diesen Blog als Merkzettel.

Die Installation und Anbindung ans APL2 hat ja reibungslos funktioniert.

Aber, was war das bloß, dass APL2Env_ nicht wie erwartet wollte? Das APL2 Hostwin meinte irgendwelche Klassen zu vermissen. Das kam alles bedeuten. Ich war sicher zu ungeduldig und habe wahrscheinlich was übersehen. Denn ...

Heute morgen habe ich eclipse installiert, einige Klassen von links nach rechts verschoben, "classpath" angepasst und - Überraschung! - APL2Env_ und Genossen zicken nicht mehr.

Hier noch drei weitere Merkposten:

Nachdem nun klar ist, dass APL2PIA kein "multi-threaded" APL2 ermöglicht, musste ich auch auf meinem neuen Rechner Java installieren, um meine Tools wie auf dem alten Rechner benutzen zu können.

Java installieren und einige Einstellungen vornehmen, testen und ok. Das war alles ganz einfach und ebenso "straight forward". Schließlich habe ich das gerade zum vierten oder fünften mal gemacht. Es lebe die Routine!

Und so geht's (s.a. APL2 User's Guide, S.168):

Java von java.sum.com downloaden. Da ich auch Java Klassen erstellen möchte, wähle ich das SDK, zur Zeit JDK 5.0 Update 6. Ansonsten reicht das Java Runtime Environemnt. Installieren ... und gut bis hier.

Möglicherweise ist Java, in welcher Variante auch immer, bereits installiert. In der Windows Eingabeaufforderung kann man dies mittels "java -version" herausfinden.

Damit ich unter APL2 auf die die Beispielklassen zugreifen und mittels Prozessor 14 ausführen kann, muss ich noch zwei Einstellungen vornehmen.

Am Montag, den 17. April 2006, schrieb ich unter "Warum nur, warum ...":

"... mag David den P12 nicht?"

Diese implizite Annahme entbehrt jeder Grundlage.

Weiter unten verstieg ich mich in der Frage:

"Warum also mag David den AP210 so sehr?"

Auch diese inhärente Behauptung entspicht nicht der Wahrheit.

Wahr ist, dass David den P12 hoch schätzt und ihn dem Hilfsprozessor 210 sogar vorzieht.

Die Redaktion entschuldigt sich an dieser Stelle in voraus eilendem Gehorsam für diesen rhetorischen Ausrutscher.