Martin Wodrich ([EMAIL PROTECTED]) schreibt: >> 1) Zun�chst versuche ich mich an der Idee einer Interpreterumgebung >> in XP.
> z.B. genau dies interessiert mich auch. Im Prinzip kann man zun�chst zwei Richtungen unterscheiden: Entweder kapselt man alle ben�tigten Routinen einschl. des Interpreters in eine Library, wie bei JED oder MC und die aus dem Programm heraus oder durch eingebundene Skripts aufgerufen werden. Mal davon abgesehen, was die Overlayverwaltung unter Pascal dazu sagt, und es einem XP- Komplettumbau voraussetzt, w�rde das vermutlich f�r ein 16-Bit-Programm zu langsam werden, von Speicherproblemen nicht zu reden. Oder man generiert eine Liste mit einer Auswahl von Prozedur- und Funktionsaufrufen des Programms und ruft den externen Interpreter als eigenes Programm auf oder l�dt ihn aus XP in ein Speichersegment und �bergibt ihm dabei die Listenadresse im Speicher. Parallel dazu mu� der Interpreter die Parameter kennen und deren Reihenfolge auf dem Stack beachten. Das Problem ist auch hier der Speicherplatz, denn XP soll dabei nicht wegswappen und damit stehen allenfalls etwas mehr als 128 KB Hauptspeicher zu Verf�gung bzw. weniger, wenn Teile aus dem Overlay nachgeladen werden sollen. Als eingebetteten Interpreter experimentiere ich mit vd. 16-Bit Forth wobei der Interpreter bereits in Forth eingebaut und interaktiv nutzbar ist, w�hrend f�r den normalen Programmlauf das Skript (=Forthsource) compiliert wird. Vermutlich wird man mit etwa 6-16 KB (mit oder ohne eingebautem Assembler) an Speicherbedarf f�r die reine Compiler/Interpreterumgebung hinkommen. Es sind noch andere Varianten wie f�r oder als Standalone-Tools denkbar, aber mich interessiert zun�chst mal nur die M�glichkeit innerhalb XPs und relativ unabh�ngig neue Funktionseinheiten zu bilden und zu testen. Das Ziel f�r mich w�re dabei nach und nach zu einem besseren internen Design zu kommen und zugleich erweiterte (Makro-)Programmier- und auch Testm�glichkeiten zu bekommen. Selbst wenn das nicht hinhaut, erwarte ich mir einige Erkenntnisse zum Programmaufbau resp. den internen Schnittstellen, da der normal Compile-Testzyklus incl. Testumgebungen bisher einfach zu viel Aufwand mit sich bringt. >> Beim Dokuformat interessiert mich als weiteres Outputformat von >> DocForm derzeit re-structured Text, also .rst, f�r das es bereits >> HTML-Konverter gibt. > Auch nicht uninteresant. Mu� man mal sehen, ob sich das etabliert hat. Immerhin gibts schon ein MIME Text/(vendor)Subtyp daf�r. -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
