Italia
Foro

Execute per Compilate

 

Jac
de
Lad
Hallo Roland!

Wäre es possibile einen Execute-Befehl per 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 possibile vielleicht compilierte Programmezeilen auszuführen (und zu dem Zweck im Speicher wieder zu decompilieren?) Ich stelle mir das sehr praktisch vor, zum Beispiel per größere Programme, per die man dann Plugins programmieren potuto.. Die könnten dann direkt ins Programm eingreifen, was im Moment noch nicht possibile ist, außer mit DLL 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:

213 kB
Kurzbeschreibung: Compilate Starten
Hochgeladen:18.08.2006
Downloadcounter31
Download
 
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.
 
18.08.2006  
 



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.
 
18.08.2006  
 




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 compilati XProfan-Code ausführen kann?
oder 3. daß ein compilertes XProfan-Programm compilati 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 per compilierte Programme, bei dem eine PRC-File zur Laufzeit so eingebunden würde, als wäre sie Teil des Programmi. 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 per weitrere PRC-Module dienen. Diese sind aber eigenständige Programme und zur Datenübergabe würden sich INI-File oder Registry-Einträge empfehlen.

Was mir noch vorschwebt (vielleicht per XPRofan 11, 12 oder 13?) sind XPDLs, XProfan Dynamic Librarys. Diese könnten Objekte, Prozeduren, etc. in compiliertem XProfan-Code enthalten, die von jedem compilati XProfan-Programm, das sie einbindet, aufgerufen werden potuto. Eine Wrapper-DLL, die naturalmente die Runtime enthalten oder nutzen müßte, potuto 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 finora neu opposto XProfan 9 ist, hätte auch gut und gerne per 2 Versionssprünge gereicht.)

Saluto
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 compilati Modus, weil in der Vergangenheit immer mal wieder kleine Abweichungen von Interpreter und Runtime aufgetaucht sind. Nicht ganz überflüssig ist der Interpreter per mich nur, weil er im Falle eines Fehlers meistens viel genauere Auskunft circa 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 per 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 potuto, 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 naturalmente noch so was wie dynamische Unità. Also Unità, die nicht direkt im Hauptprogramm stecken, sondern in einer anderen File. 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-File 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 un 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?
 
18.08.2006  
 




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 potuto 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: DLL werden ja im Speicherbereich des Hauptprogrammes corsa. 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  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Topic-Options

1.940 Views

Untitledvor 0 min.
Walter25.02.2018
Untitled26.02.2011

Themeninformationen



Admins  |  AGB  |  Applications  |  Autori  |  Chat  |  Informativa sulla privacy  |  Download  |  Entrance  |  Aiuto  |  Merchantportal  |  Impronta  |  Mart  |  Interfaces  |  SDK  |  Services  |  Giochi  |  Cerca  |  Support

Ein Projekt aller XProfaner, die es gibt!


Il mio XProfan
Private Notizie
Eigenes Ablageforum
Argomenti-Merkliste
Eigene Beiträge
Eigene Argomenti
Zwischenablage
Annullare
 Deutsch English Français Español Italia
Traduzioni

Informativa sulla privacy


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie