| |
| |
|
Jac
de
Lad | Hallo Roland!
Wäre es möglich einen Execute-Befehl für Compilate zu machen? Ich weiß, das ist sicher schwierig, da es nicht sinnvoll ist, den ganzen Interpreter in die Runtime zu quetschen  Aber wäre es möglich vielleicht compilierte Programmezeilen auszuführen (und zu dem Zweck im Speicher wieder zu decompilieren?)  Ich stelle mir das sehr praktisch vor, zum Beispiel für größere Programme, für die man dann Plugins programmieren könnte..  Die könnten dann direkt ins Programm eingreifen, was im Moment noch nicht möglich ist, außer mit DLLs beispielsweise, die aber auch nicht einfach so Profan-Variablen setzen können...
Jac  |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 18.08.2006 ▲ |
|
| |
|
|
Michael
Dell | Hallo Jac,
dachtest Du dabei an sowas: |
|
| |
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 18.08.2006 ▲ |
|
| |
|
|
 | Nun Jacob an sowas hatte ich auch schon gedacht - und es geht tatsächlich!
Ich habe angedacht hierfür eine Include zu schreiben (oder eine Unit?) - diese soll dann XProfanCode selbst interpretieren und ausführen. Ein XProfan im XProfan sozusagen. Ich glaube das geht. Natürlich wird es langsam sein - aber ich glaube das spielt dann nur eine Nebenrolle. |
|
| |
| |
| |
|
|
| Nachtrag:
Das XProfan im Xprofan kann eine eigene - eine noch einfachere Syntax als XProfan haben.
Es würde quasi eine Programmiersprache mit XProfan programmiert.
Ich kann ja bei Gelegenheit hierfür mal einen Anfang machen. |
|
| |
| |
| |
|
|
RGH | Hallo Jacob,
was genau schwebt Dir vor?
1. daß ein compiliertes XProfan-Programm XProfan-Quellcode ausführen kann?
oder 2. daß der XProfan-Interpreter compilierten XProfan-Code ausführen kann?
oder 3. daß ein compilertes XProfan-Programm compilierten XProfan-Code so ausführen kann?
Version 1 und 2 haben das Problem, daß dann der Interpreter auch die Runtime enthalten müßte und die Runtime auch den Interpreter. Das ist sicher nicht so einfach machbar, aber ein interessanter Gedanke.
Version 3 wäre in der einfachsten Variante eine Entsprechung des Execute-Befehls für compilierte Programme, bei dem eine PRC-Datei zur Laufzeit so eingebunden würde, als wäre sie Teil des Programmes. Sie greift also auf die gleichen Variablen, etc. zu. Auch nicht ohne.
Was ja schon immer (seit Version 1.3) geht, ist folgendes: Ein compiliertes und zur EXE gelinktes Programm kann als Runtime für weitrere PRC-Module dienen. Diese sind aber eigenständige Programme und zur Datenübergabe würden sich INI-Dateien oder Registry-Einträge empfehlen.
Was mir noch vorschwebt (vielleicht für XPRofan 11, 12 oder 13?) sind XPDLs, XProfan Dynamic Librarys. Diese könnten Objekte, Prozeduren, etc. in compiliertem XProfan-Code enthalten, die von jedem compilierten XProfan-Programm, das sie einbindet, aufgerufen werden könnte. Eine Wrapper-DLL, die natürlich die Runtime enthalten oder nutzen müßte, könnte diese Funktionalitäten auch anderen Windowsprogrammen zur Verfügung stellen. Bislang exitiert so etwas allerdings nur in meinem Kopf und einigen handschriftlichen Notizzetteln ...
Aber vorerst will ich XProfan 10 fertig bekommen, und da wird es sicher keine weiteren neuen Features mehr geben.* (Ich denke, das was bislang neu gegenüber XProfan 9 ist, hätte auch gut und gerne für 2 Versionssprünge gereicht.)
Gruß
Roland
* Ok, Version RC2 wird als letzten Parameter bei oGL(Init,...) nicht nur 0 und 1 zulassen, sondern 0 - 5 und somit 5 verschiedene Lichtarten bieten, aber das ist wirklich die letzte Erweiterung. |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 18.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | Hm...meiner Meinung nach ist der Interpreter so oder so fast überflüssig. Ich teste alle meine Programme fast ausschließlich im compilierten Modus, weil in der Vergangenheit immer mal wieder kleine Abweichungen von Interpreter und Runtime aufgetaucht sind. Nicht ganz überflüssig ist der Interpreter für mich nur, weil er im Falle eines Fehlers meistens viel genauere Auskunft über die Ursache geben kann, die Runtime gibt meistens nur Fehler in Zeile soundso aus, was dann gemappt werden muss...sehr kompliziert und zeitaufwändig.
Meine Idee ist, dass ich Plugins schreiben kann, quasi wie für Firefox. Dort können die Plugins auch direkt das Vrehalten des Browsers ändern und haben offensichtlich Zugriff auf die Variablen von Firefox. Ich hab schon zwei Programme in Profan geschrieben, die andere als Plugins ausführen und die Runtime des aufrufenden Programms verwenden, soweit funktionierts ganz gut. Sobald das aufgerufene Proggi aber, beispielsweise, im %HWnd des aufrufenden Proggis ein Steuerelement erstellen will, wirds Mist, weil mir entweder die Rechte fehlen oder anderer Kram dazukommt.
Deswegen habe ich zuerst gedacht, dass man quasi den Befehl Execute 1:1 umsetzen könnte, dazu müssten die Plugins aber uncompiliert sein, und falls doch compiliert wird das Ganze unnötig schwer...
Also hab ich versucht eine eigene Batchsprache zu entwickeln (die ich ja mühelos verschlüsseln, compilieren, was auch immer, kann). Leider wir ddas Ganze dann doch sehhhhhr langsam und so richtigen Zugriff (ich erwähne hier noch mal die im Hauptprogramm declarierten Variablen) auf ALLES habe ich nicht. Eine gute Idee wäre natürlich noch so was wie dynamische Units. Also Units, die nicht direkt im Hauptprogramm stecken, sondern in einer anderen Datei. Das würde im Sinne von Plugins aber nur funktionieren, wenn die Pfade und Dateinamen dazu dynamisch, also in Stringvariablen, angegeben werden könnten. Und dann müsste das Hauptprogramm auch in der Lage sein, den entsprechenden Code nicht bei Programmstart zu laden, sondern eben erst an der entsprechenden Programmzeile.
Versteht ihr worauf ich hinaus will???
Jac  |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 18.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | | @Michael: Das Prinzip des Aufrufs der Runtime mit PRC-Datei ist klar. Das habe ich bisher auch benutzt. Das Ganze wirkt auch recht schön mit SetParent, weil man dann, den Eindruck hat, dass das Ganze wirklich ein Plugin ist. Leider gehts entweder so, dass ich die relevanten Variablen in eine INI schreibe oder als Parameter übergebe, das ist nicht sehr elegant und effektiv. Außerdem gibts immer wieder Anzeigeprobleme wenn das Fenster verdeckt wird...sehr mühsam! |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 18.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | @iF: Ich hab mal sowas wie eine Programmiersprache mit XProfan 8 geschrieben, war aber am Ende ziemlich sinnlos. Das müsste dann schon direkt in der Runtime integriert sein oder eine DLL sein, weil sonst ists zu langsam. Und bei ner DLL, denke ich, ists relativ schwer hinzukriegen, dass man auf ALLES Zugriff hat...
Jac |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 18.08.2006 ▲ |
|
| |
|
|
| | Nun ich denke nicht das es Sinn macht auf alles Zugriff zu haben. Den Zugriff sollte das Hauptprogramm steuern - also ist es doch eher eine Frage dessen wie das Hauptprogramm die PlugInNachrichten verarbeitet - oder? |
|
| |
| |
| |
|
|
Michael
Dell | XProfan Dynamic Librarys, klingt Spannend! Darauf zu warten lohnt bestimmt! (aber meine armen Nerven...  ) |
|
| |
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 19.08.2006 ▲ |
|
| |
|
|
Michael
Wodrich | In FireFox wird den PlugIns eine API zur Verfügung gestellt. Die regelt, auf was man Zugriff hat. Auf diese Weise könnte es auch in Profan programmiert werden. Und der Datenzugriff sollte nicht global gesehen werden, sondern wie bei Objekten: da sagt man auch gib mal Wert X oder setze Wert Y. Für die Ausführung ist dann das Objekt zuständig - trifft auch auf selbsterstellte API-Funktionen zu.
Die von Roland angesprochene Profan-DLL: DLLs werden ja im Speicherbereich des Hauptprogrammes ausgeführt. Damit fallen dann schon mal einige Begrenzungen weg - eine gute Idee.
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 19.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | | Profan-DLL und XPDL klingt gut! So in etwa stelle ich mir das vor... |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 20.08.2006 ▲ |
|
| |
|
(767)
Deutsch
English
Français
Español
Italia