Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

  • ??? - Ich hab bereits alles beschrieben. Eigentlich waren die ersten Beispielskripte dafür gedacht. Aber okey... Ich schreib dir noch ein Beispiel. <.<

    Du brauchst nicht genervt zu sein. Das sorgt nicht unbedingt für eine gute Gesprächsgrundlage.


    Vielleicht sehe ich es nicht. Ich spreche von den Files in RE: Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen


    Dein erstes Beispiel ruft nur eine simple Lua Funktion auf,

    Dein zweites Besipiel schiebt ein Int in die Lua Welt,

    Dein drittes Beispiel endet in einem Programmabbruch.


    Kann ich Plugins zur Lua-Laufzeit nachladen? - Also im AutoIt-Kontext gesprochen (wo es nicht möglich ist): eine UDF herunterladen, ins Scriptverzeichnis einfügen, und während das Programm schon läuft Includen?

    Danke,

  • Du brauchst nicht genervt zu sein. Das sorgt nicht unbedingt für eine gute Gesprächsgrundlage.

    Huh, ich bin nicht genervt. o.o

    Ich glaube wir reden nur aneinander vorbei. :P

    Wenn ich genervt wäre würde ich schlichtweg mich verkrümeln und den Thread ignorieren.


    Dein drittes Beispiel endet in einem Programmabbruch.

    Versuch mal #AutoIt3Wrapper_UseX64=y davor zu packen. Da war die Lua UDF noch nicht ganz fertig und ich hatte es nur in 64 bit getestet.


    Kann ich Plugins zur Lua-Laufzeit nachladen?

    Ja? Das ist ja der Sinn dahinter. Schau dir Post #18 nochmal an. Da wird alles direkt geladen und ist direkt global verfügbar. Wenn du ein neues Objekt in deiner GUI anlegst kannst du es auch direkt verwenden ohne Neustart. Das ganze lässt sich auf alles übertragen. Ganze Skripte können geladen und ausgeführt werden zur Laufzeit.


    Ich bin gerade noch dabei dir das Beispiel für AutoIt Objekte zu machen.


    Mir ist durchaus klar an was für ein Problem du sitzt. Eine Lua integration ist mein erster Vorschlag dafür. Es macht eigentlich genau das was du wünscht. Du kannst das auch (wie bereits gesagt) mit AutoIt und IPC umständlicher lösen. Ist halt nur mehr aufwand und vermutlich mehr Anfälliger für Fehler (wenn dir irgendwelche Prozesse abschmieren etc.)

  • Hey,

    Ja? Das ist ja der Sinn dahinter. Schau dir Post #18 nochmal an. Da wird alles direkt geladen und ist direkt global verfügbar. Wenn du ein neues Objekt in deiner GUI anlegst kannst du es auch direkt verwenden ohne Neustart. Das ganze lässt sich auf alles übertragen. Ganze Skripte können geladen und ausgeführt werden zur Laufzeit.

    Da habe ich gestern irgendwie Module und Plugins durcheinandergewürfelt und die Frage falsch gestellt, sorry. Dass alle Funktionen und Globals in der Lua Laufzeitumgebung verfügbar sind, hab ich kapiert. Wenn ich eine Funktionssammlung - also ein Lua Module/Rock - runterladen und integrieren will geht das on the fly. Coole Sache.

    Plugins (base, file, io, ...) entsprechen dann eingebauten AutoIt Funktionen? Kann ich Plugins zur Laufzeit aktualisieren/nachladen, nachdem schon Module geladen/Funktionen ausgeführt wurden?

    Versuch mal #AutoIt3Wrapper_UseX64=y davor zu packen. Da war die Lua UDF noch nicht ganz fertig und ich hatte es nur in 64 bit getestet.

    Und ich nur im 32 Bit Mode - Funktioniert, danke.

    Mir ist durchaus klar an was für ein Problem du sitzt. Eine Lua integration ist mein erster Vorschlag dafür. Es macht eigentlich genau das was du wünscht. Du kannst das auch (wie bereits gesagt) mit AutoIt und IPC umständlicher lösen. Ist halt nur mehr aufwand und vermutlich mehr Anfälliger für Fehler (wenn dir irgendwelche Prozesse abschmieren etc.)

    Dass Du mein Problem verstehst hab ich nicht bezweifelt - ich beschwer' mich ja gar nicht. Ich glaube, es fällt mir schwer den Umfang und die Vision zu beschreiben. Lua scheint ne schicke Geschichte zu sein und ich kann mir auch gut vorstellen, das in Teilen der Anwendung zu ermöglichen. Aber dann gerne als Alternative zu AutoIt (deswegen die Frage nach dem Zugriff auf die Objekte mittels RoT). Meine persönliche Vision ein geschlossenes System - alles ist eins (Die oben erwähnte Trennung in Business-Objekte und System-Objekte eigentlich auch nur temporär.) . Ein System, in einer Sprache geschrieben - mit einer Sprache erweiterbar - direktes Feedback, weil alles direkt am Bildschirm stattfindet - keine statik, alles ist polymorph und veränderbar - GUI Elemente die die Objekte repräsentieren. Am liebsten hätte ich die Programmiersprache Self - in abgespeckt und ein ganz klein bisschen anders, und simpler - einfach zu verstehen und nutzen im Büro/Enterprise-Kontext. Mit moderner GUI.


    Lua kann das mit Sicherheit auch alles leisten - und wäre einerseits für simple Aufgaben wie Datentransformationen einfach genug um von einem Key User getippt zu werden - aber auch mächtig genug um das ganze GUI Handling, IPC, Printing, Datenbank, Filehandling zu erledigen. Alles cool. Ich bin mit den Services und der Laufzeitumgebung meiner Applikation aber schon weit fortgeschritten und am Point of no Return vorbei - alles noch einmal auf Lua umzubauen, ist Budgettechnisch nicht mehr drin und würde auch die weitere Entwicklung verlangsamen. Da fehlt dann einiges an Routine um flott zu coden - 12 Jahre Erfahrung krieg' ich in Lua demnächst nicht mehr Zusammen. Zeittechnisch fällt das also auch weg; ich habe bestimmte Ziele die ich einhalten muss. Deswegen ist es AutoIt und bleibt es AutoIt als "first language". Der im ersten Post beschriebene Workaround funktioniert für ja mich auch - die Objekte mit neuen/geänderten Methoden werden in Worker ausgelagert bis die Applikation neu startet. Zugriff auf alle Daten der Applikation gibts quasi automatisch da alles in einem Applikation Objekt liegt, das ich einfach mittels Parameter übergeben kann. Es ist im Prinzip nur die Frage der Eleganz, die ich im ersten Post stelle.


    Übrigens: Wenn ich nicht ausgiebig Antworte, ist das nicht als unhöflich zu verstehen - ich bin wie oben gesagt dankbar für den Hinweis und die Arbeit mit den Lua Scripten - ich versuche aber aus o.g. Gründen bewusst den Thread in eine bestimmte Richtung zu lenken. - und die Richtung ist AutoIt. ;) Ich passe auch noch einmal den Titel und ersten Post an, damit der Hinweis auf AutoIt klarer wird.


    Cheers,

  • Kann ich Plugins zur Laufzeit aktualisieren/nachladen, nachdem schon Module geladen/Funktionen ausgeführt wurden?

    Ja, kannst du :P

    In Lua kannst du Funktionen / Variablen / Objekte etc. nach belieben überschreiben und damit auch zur Laufzeit aktualiseren. Hier mal ein sehr vereinfachtes Beispiel:

    Entsprechend die Ausgabe:

    Code
    λ lua54 "c:\Users\Yjuq\Desktop\code.lua"
    function 1
    function 2

    Nur um mal deine Frage oben zu beantworten. Ein Modul ist in Lua nichts weiteres (zumindest meistens) als eine einfache Funktionssammlung. Du kannst also das Ganze "hotpatchen".


    Da fehlt dann einiges an Routine um flott zu coden - 12 Jahre Erfahrung krieg' ich in Lua demnächst nicht mehr Zusammen.

    Lua ist wirklich einfach. Und der Unterschied zu AutoIt ist auch nicht besonders groß. Gib dir ne Woche Zeit um dich einfach mit den Basics zu beschäftigen und du hast das nötigste für Lua drin. Lua hat nicht so viele Features dass du davon überrumpelt werden könntest. :P


    Am liebsten hätte ich die Programmiersprache Self - in abgespeckt und ein ganz klein bisschen anders, und simpler - einfach zu verstehen und nutzen im Büro/Enterprise-Kontext.

    Lua... ^.^


    Ich bin mit den Services und der Laufzeitumgebung meiner Applikation aber schon weit fortgeschritten und am Point of no Return vorbei - alles noch einmal auf Lua umzubauen,

    Ja, das war mir bei meinen ersten Post schon bewusst. Ich sage ja auch nicht alles umbauen, ich sage nur Lua intigrieren für zukünftige Sachen. Was du hast kannst du einfach einbinden. Du brauchst nicht viel umschreiben, lediglich alles was du hast für Lua einmal registrieren. Das war's. Deswegen hab ich dir das ja auch vorgeschlagen.


    Zugriff auf alle Daten der Applikation gibts quasi automatisch da alles in einem Applikation Objekt liegt, das ich einfach mittels Parameter übergeben kann. Es ist im Prinzip nur die Frage der Eleganz, die ich im ersten Post stelle.

    Das du eine funktionierende Lösung hast ist mir auch klar. Selbst mit dieser Information würde ich immernoch Lua vorschlagen...


    Lua ist nun perfekt für solche Projekte geeignet. Deswegen schlage ich es ja auch vor. Ob du das eleganter in AutoIt lösen könntest? Keine Ahnung, wenn ROT funktioniert dann reicht es aus.


    Hier mal noch ein letztes Beispiel wo ich gerade dran saß:

    Ich war gerade dabei noch die AutoIt Objekte einzubinden, also eine einfache Funktion die dir ermöglicht auf alle deine vorhandenen AutoIt Objekte zuzugreifen. Die autoit() Funktion ist die Schnittstelle zu den gesamten AutoIt Built-In Funktionen. Ich hab aber leider gerade ein paar Probleme mit dem AutoIt Objekten weil Eval / Assign / Execute für diese bei Zuweisungen nicht so einfach funktionieren. War gerade dabei zu schauen ob ich nicht die Invoke Methode aus dem IDispatch Interface für diese Objekte nicht irgendwie aufrufen könnte. :P


    Um aber mal zurück zu rudern:

    Ich bezweifel dass du das mehr eleganter in AutoIt lösen könntest als die Lösung die du momentan hast. Zumindest fällt mir da so nichts mehr dazu ein. Falls das deine Ursprungsfrage eher beantworten sollte. Ich hatte lediglich Lua vorgeschlagen weil es für deine Ansprüche eigentlich eine sehr gute Lösung ist. Vielleicht hat jemand anderes noch eine Idee? Mich wundert es sowieso warum sich hier keiner meldet. :P

  • Ich war gerade dabei noch die AutoIt Objekte einzubinden, also eine einfache Funktion die dir ermöglicht auf alle deine vorhandenen AutoIt Objekte zuzugreifen.

    Das Gegenstück zu AutoIt's ObjGet() in Lua würde mir schon reichen ;)


    Vielleicht hat jemand anderes noch eine Idee? Mich wundert es sowieso warum sich hier keiner meldet. :P

    Ich denke das Problem ist, dass ,
    1) sich Threads schnell "verrennen", und Leute nicht unbedingt gewollt sind, einer ellenlangen sehr technischen Konversation zu folgen.
    2) sich Leute weniger interessieren, wenn es schon einen Workaround gibt oder im Thread schon eine mögliche Lösung vorgeschlagen wurde. (Frei nach dem Motto: "Soll er das doch irgendwie reinbasteln und fertig!".)

    3) die landläufige Meinung ist, dass es "nicht geht". AutoIt kann das nicht und Punkt. Aber die Erde war auch einmal der Mittelpunkt des Universums und alles andere war Quatsch.


    Über die Jahre habe ich einige Versuche in diese Richtung u.a. mittels Multithreading oder Injection, etc. mitbekommen, und wahrscheinlich die Hälfte der Erkenntnisse daraus wieder vergessen. Bei mir hängengeblieben, ist aber, dass es noch keiner so wirklich geschafft hat. Und das verstehe ich einfach nicht! Hier (und auch im englischen Forum) sind so viele schlaue Leute - da wird der verrückteste Scheiß gebastelt... aber keiner schafft es, den AutoIt Interpreter zu bändigen?!


    Ich finde diesen Thread hier so interessant - da sieht man was passiert, wenn man so eine Frage im Englischen Forum stellt. Der gute Busti hat alles versucht und immer wieder neue Ansätze präsentiert bis er kleingeredet wurde. https://www.autoitscript.com/f…etreive-the-struct-of-it/



    Also Leute!


    Die Frage ist und bleibt offen: Wie generiere ich (möglichst elegant) eine AutoIt-Funktion zur Laufzeit? :)

  • Das Gegenstück zu AutoIt's ObjGet() in Lua würde mir schon reichen

    Das würde nicht helfen da Lua COM von sich aus nativ nicht unterstützt. :P

    Da müsstest du schon viel Aufwand betreiben um COM in Lua lauffähig zu bekommen. Da ist es einfacher eine Wrapper Funktion in AutoIt zu deklaieren und diese per Lua aufzurufen um Objekte zu manipulieren. ^^


    Aber ich kann es mal probieren ob ich das rohe COM Objekt nicht einfach in Lua als Userdata zur verfügung stelle und dann schaue was passiert. Vielleicht überrascht mich Lua ja und es kann die COM Objekte doch direkt handeln. Das wäre ne ziemliche Überraschung.


    Über die Jahre habe ich einige Versuche in diese Richtung u.a. mittels Multithreading oder Injection, etc. mitbekommen

    Jup, ebenfalls. Multithreading ist zwar möglich aber aufwendig. Du kannst nicht einfach auf Variablen und Funktionen zugreifen die AutoIt zur Verfügung stellt. Da brauchst du schon eigene Mechanismen um alles Thread Safe zu verbasteln. Der Grund ist dass der AutoIt Interpreter intern globale Variablen bei einigen sachen nutzt die schlichtweg das gesamte Konzept über die Bühne schmeißen. GUI + Multithreading ist da schon Problem Nummer 1. Heißt nicht dass solche Dinge nicht funktionieren, aber da muss man halt Umstände in Kauf nehmen von der gewohnten Art in AutoIt zu programmieren. Ich glaube der Aufwand ist einfach schlicht zu groß...


    AutoIt hat technisch gesehen keine Limitierungen. Du kommst immer irgendwie drum herum. Die Frage ist nur in wie fern der Aufwand letzten Endes sich für das Vorhaben lohnt. Es existieren zig andere Tools die solche Dinge besser lösen als AutoIt. Da ist es einfacher solch ein Tool statdessen zu benutzen.


    Die Frage ist und bleibt offen: Wie generiere ich (möglichst elegant) eine AutoIt-Funktion zur Laufzeit?

    Was mir noch einfallen würde wäre die Funktionen zu kompillieren mit AutoIt und dann den Funktionscode auszulsen und diese in ausführbaren Memory zu packen in dein laufendes Skript. Etwa so ähnlich wie ein JIT Compiler. Ist nur eine Idee könnte aber funktionieren. Ob das nun "eleganter" ist wage ich zu bezweifeln, aber wäre noch eine Möglichkeit.


    Aber da bin ich mir ziemlich unsicher. Ich glaube in einer AutoIt exe wird der Interpreter mitgeliefert und das Skript schlichtweg nur interpretiert. Kann also sein dass die Variante also schon von Vorne herein zum Fehlschlag verleitet ist.


    Da sind Varianten über IPC und Multiprocessing durchaus realistischer.

  • Ich bin auch nur kurz hereingeschneit SEuBo

    Die einzige reine AutoIt-Möglichkeit ist doch, dass du den zur Laufzeit in AutoIt geschriebenen Code in eine Datei schreibst und die mit deiner eigenen oder der auf dem Zielsystem installierten Au3.exe ausführst. Alle deine im Script vorhandenen Daten kannst du an das von deinem Skript geschriebene Programm übergeben. Entweder per Quelltext oder Kommandozeile, etc. Das genügt schon, wenn kein weiterer Austausch während der Laufzeit stattfinden muss. Dazu gäbe es hier Threads wie interprozesskommunikation oder so ähnlich.