| |
|
|
| Ich glaube Rolands Anpassungen der Variablensichtbarkeit sind Vorbereitungen eines echten ProcAddr rein mit XProfan - ist imho aber auch kein Geheimnis. ^^
Danach meckert dann also vlt. XProfan so oder vlt. noch strenger rum als xpse, der diese "ordentliche" Variablensichtbarkeit schon immer vom Programmierer abverlangte*. ^^ (vlt. dann für die gut, die ihn ohnehin schon immer genutzt haben ^^)
*) aber Abstriche beim Meckern macht für mehr Kompatiblität
Wäre natürlich prima, wenn diese Abstriche beim Meckern irgendwann nicht mehr gemacht werden müssten, sodass Programmfehler eindeutiger identifiziert werden könnten.
Andererseits meine ich aber auch, dass für echtes ProcAddr in XProfan die Variablensichtbarkeit derart ganicht angepasst werden müsste, aber Roland hat da vlt. schon einen fertigen Plan um Kopf. ^^
Ich glaube, per Memorymodule-Verfahren gingen auch interpretierte "echte" Threads und echtes ProcAddr zu ermöglichen auch ohne Anpassungen bezüglich der Variablensichtbarkeit.
Jetzige Runtime.Exe liest aus sich den Source und interpretiert diesen, somit jetzig: Interpretiere(Source).
Die jetzige (natürlich bildliche) Funktion Interpretiere - also das ganze XProfan - vlt. komplett in eine DLL abwandern - die neue Runtime.Exe wäre dann (bildlich):
interpreter=useMM(runtime) interpreter.run(interpreter,source) freeMM(interpreter)
Somit wäre auch eine Funktion Eval bzw. eine Funktion Interprete möglich, warum sollte man denn auch nicht beliebig viele XProfan-Interpreter-Instanzen erzeugen können und diesen beliebigen Source senden können - virtuelle Funktionen halt wie Eval bei PHP und JS.
Wenn danach dann per interpreter.run(interpreter,source) für Threads bzw. echtes ProcAddr, der Source vor Übergabe an interpreter.run auch noch angepasst werden kann, kann auch Threadsynchonisation stattfinden und der Source könnte auch mit Blockaden für kritische Sektionen gespickt werden - wo eben auf eine globalere Variable zugegriffen wird.
Ein Beispiel kann ich dafür (noch) nicht posten, da ich selbst keine Funktion Interprete hergestellt habe - so ein kleiner mit XProfan geschriebenen Mini-Interpreter wäre aber bestimmt mal ganz lustig. ^^ |
|
|
| |
|
|
|
Nico Madysa | |
|
| |
|
|
|
Jörg Sellmeyer | ist es Absicht, daß dieser Thread nicht via RSS verfügbar ist? Da kommt bei mir nur die Login-Seite. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 26.03.2010 ▲ |
|
|
|
|
| @Nico: Jupp, meine ich wirklich. Ob und wie oder warum nicht, dass kann nur Roland beantworten.
@Jörg: Jupp, habe diesen Thread einfach mal deklariert als "nur eingeloggte User", damit ich besser sehen kann, wer bereits gelesen hat: [...] , |
|
|
| |
|
|
|
Frank Abbing | Bei einer Umstellung auf 64 Bit müssten alle nativen Codes wieder umgeschrieben werden... |
|
|
| |
|
|
|
| @Frank: Könntest Du mir den Sinn zwischen dem Thema und Deinem Beitrag etwas näher bringen? Ich wüsste jetzt nämlich nicht, inwiefern jetzt die Bitbreite des Prozesses eine Rolle hierbei spielt, die sie nicht ohnehin spielen würde. ^^ Das, was ich meine, funktioniert jedenfalls mit 32 und auch 64 Bit. |
|
|
| |
|
|
|
Frank Abbing | Dann hatte ichs nicht richtig verstanden oder du nicht gut genug erklärt. |
|
|
| |
|
|
|
| Der Beitrag ist einfach zu lang, Frank. |
|
|
| |
|
|
|
Frank Abbing | Da auch niemand sonst auf den Inhalt reagiert wird es so sein. |
|
|
| |
|
|
|
| Weist Du doch garnicht, normale Leute fragen ja nach, wenn sie was nicht verstanden haben - es aber verstehen wollen.
Bisher ist mir ja nur bekannt, dass Du vielleicht was durcheinander bringst - auf meine Nachfrage bist Du ja nicht eingegangen.
Von anderen Mitgliedern hingegen _weiss ich, dass sie es verstanden haben - da steht doch auch nichts Grosses sondern nur eine Idee. ^^ |
|
|
| |
|
|
|
Nico Madysa | Ich habs auch nicht verstanden, aber mir hat Nachfragen ja auch nicht viel gebracht. |
|
|
| |
|
|
|
Frank Abbing | |
|
| |
|
|