Prozedureinsprungpunkt "luaL_register"

1. offizieller Beitrag

    Das Thema "luaL_register" ist schon etwas älter, hier und hier wurde z.B. darüber geredet. Soweit ich mich erinnern kann, fällt dadurch die Möglichkeit weg, DLLs einzubinden. Vorallem die shell.dll wurde von Usern schmerzlich vermisst. Deshalb hier vorerst die Fragen:

    • Hat sich da etwas getan? Gibt es "luaL_register" wieder oder einen Ersatz?
    • Hat jemand mit Neil Hodgson geredet? Was kam dabei raus?
    • Falls nicht: Welche Funktionen werden von euch denn hauptsächlich benutzt/vermisst?
    • Kann man vielleicht Ersatzfunktionen erstellen?

    Ich habe einen möglichen Workaround gefunden, um das Aufblitzen des CMD-Fensters bei "os.execute" zu verhindern. Wieviel würde das denn nutzen, bezüglich des "luaL_register" Problems? Wenn es z.B. 1 von 4 Problemen wäre, könnte der Workaround Licht am Ende des Tunnels bedeuten. :) Wenn es z.B. 1 von 40 Problemen wäre, vergesst meinen Beitrag. :(


    Ok, bitte steinigt mich nicht, ich habe vieles über SciTE und Lua wieder vergessen und auch die Zusammenhänge, um was es genau ging, aber ich meine es gut! :saint:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    • Offizieller Beitrag
    Zitat von Professor Bernd

    um das Aufblitzen des CMD-Fensters bei "os.execute" zu verhindern.

    Das ist ja in neuer SciTE-Version möglich mit

    Code
    in SciTEUser.properties:
create.hidden.console=1

    (Bin mir nicht sicher, ob die letzte SciTE4AutoIt das implementiert hat, da ich diese nicht nutze)


    Der Fix, mit dem das Laden von Dll ermöglicht wird (https://sourceforge.net/p/scintilla/bugs/2058/) ist beim Kompilieren von SciTE anzuwenden, kann also von uns nicht genutzt werden. Da müsste Jos tätig werden. - Aber er hat sich ja im Bugtracker klar positioniert: "Wont fix" (wird nicht behoben).

    Ich hatte bisher noch keine Lust so tief in die Materie einzutauchen, dass ich mir SciTE selbst kompiliere - aber vielleicht ist das die einzige Lösung.

    Zitat von BugFix

    Ich hatte bisher noch keine Lust so tief in die Materie einzutauchen, dass ich mir SciTE selbst kompiliere - aber vielleicht ist das die einzige Lösung.

    Da bin ich dabei, wenn du das umsetzen willst! :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Zitat von BugFix

    Das ist echt witzig. Denn im Link stehen für Text und Link dieselben (korrekten) Angaben.

    Stimmt, das ist seltsam :


    Ich habe den Beitrag kurz überflogen, aber da ist viel von Linux die Rede.

    Was würdest Du vermuten : "Wäre es für Jos ohne großen Aufwand möglich, diesen Fix einzubauen ?"

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Zitat von BugFix

    In der Linuxvariante ist es wohl nur eine Codezeile. Könnte also für Windows ähnlich sein.

    Ich verfolge dieses Thema zwar nur am Rande, aber das Hauptargument von Jos ist ja, dass er keine Fixes macht, die nicht bereits Eingang in den Standardquellcode gefunden haben. Das ist grundsätzlich nachvollziehbar und natürlich sein gutes Recht.


    Wie Du an anderer Stelle geschrieben hast, werden dadurch aber viele nützliche LUA-Skripte de facto unbrauchbar, sofern sie diese Variante des Ladens von Dll's verwenden. Es wäre schon bedauerlich, falls man dies mit ein Paar Codezeilen bereinigen könnte.

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Zitat von Musashi

    "Wäre es für Jos ohne großen Aufwand möglich, diesen Fix einzubauen ?"

    Wenn ich es richtig verstanden habe, war luaL_register eine exportierte Funktion aus dem in SciTE verankerten Lua, die es in der aktuellen Lua-Version aber nicht mehr gibt.


    Hier ist sicher in allen Fällen mehr als eine Zeile Code nötig, um luaL_register aus einer älteren Lua-Version mit einzupflegen... wobei noch zu klären wäre, ob die Funktion auch kompatibel mit der neuen Lua-Version ist.

    Zitat von Bitnugger

    Wenn ich es richtig verstanden habe, war luaL_register eine exportierte Funktion aus dem in SciTE verankerten Lua, die es in der aktuellen Lua-Version aber nicht mehr gibt.

    Musashi 29. September 2020


    Code
    void luaL_register (lua_State *L, const char *libname, const luaL_Reg *l);

    Lua 5.2 Reference Manual, 8.3 – Changes in the API

    Function luaL_register is deprecated. Use luaL_setfuncs so that your module does not create globals.

    Code
    void luaL_setfuncs (lua_State *L, const luaL_Reg *l, int nup);


    Damit ist mein LUA-Latein am Ende. Leider weiß ich nicht, wie man das nutzt und ob Jos v.d.Z. dazu eine Fix einbauen kann. Aber meine Vermutung ist, dass das eher von Neil Hodgson gefixt werden kann, so wie er es wohl für Linux schon getan hat: #2058 Default build on Linux has dynamic libraries disabled und Bug [#2058]. On Linux, enable Lua to access dynamic libraries.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Boah, das ist hart! =O Ist das das Aus für DLLs in Lua? Man kann ja nicht ewig eine alte SciTE Version benutzen, um das Feature zu behalten.


    Somit ist es quasi "amtlich", dass DLLs in SciTE's Lua für unabsehbare Zeit nicht mehr eingebunden werden können. Wäre es nicht möglich, an einem Workaround oder an einer Alternative zu arbeiten? Kann man nicht die häufigst genutzen Funktionen aus den DLLs in Lua nachbilden, oder in AutoIt? In PSPad benutze ich die bescheidenen Fähigkeiten von VBScript überwiegend, um AutoIt Scripts aufzurufen. Autoit sollte doch alle Funktionen bewältigen, die DLLs können, oder?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    • Offizieller Beitrag

    Ich habe keine Ahnung, was "require" intern mit einer Dll veranstaltet. Vermutlich wird die Dll in den Speicher geladen, ihre Funktionen werden ausgelesen und im Globalen Table bereitgestellt.

    Dazu müssen die Dll's irgendeine bestimmte Form aufweisen, von der ich wiederum auch keine Ahnung habe. Ich weiß nur, dass "normale" Dll für Lua im SciTE-Lua nicht geladen werden können.

    Nachbilden in Lua lassen sich viele Funktionen nicht.


    Wie es nun weiter geht....?

    • Offizieller Beitrag

    Frage an alle, die die aktuelle SciTE4AutoIt-Version installiert haben:

    Funktioniert dort schon "quiet" os.execute?

    Falls ja, ist zwar auch keine der vorhandenen Dll zu gebrauchen, aber man könnte sich neue schreiben und diese über "os.execute" im Hintergrund aufrufen, gewissermaßen ein "execrequire" (klingt gut, vielleicht behalte ich den Funktionsnamen ;)).


    Um das zu testen, einfach in der SciTEUser.properties mal einfügen:

    Code
    # hatte ich vergessen - diese property muss aktiviert werden
create.hidden.console=1

command.name.19.*=OS Execute Calc
command.19.*=dostring do local cmd = 'start "" "calc.exe"' os.execute(cmd) end
command.mode.19.*=subsystem:lua,savebefore:no
command.shortcut.19.*=Ctrl+Alt+F5

    command-Nr (hier 19) anpassen, wenn ihr nichts eigenes vergeben habt, könnt ihr beruhigt irgendeinen Wert zwischen 40 und 50 nehmen, die sind dann definitiv noch frei.

    Evtl. noch den Shortcut anpassen, falls bereits genutzt.


    Damit wird dann der Windows-Rechner aufgerufen, mit - oder ohne kurz flashendem CMD-Fenster. Gebt mir dann bitte mal Bescheid.

    Ich habe das neueste SciTE installiert und deinen Code getestet. (Muss man für "quiet" os.execute noch irgendwas einstellen?) Ergebnis war wie in meiner Erinnerung vor ein paar Monaten:


    Win 7: DOS Fenster blitzt deutlich zu sehen auf.

    Win 10: Das Aufblitzen ist nicht zu sehen. Soweit ich mich erinnere, hat das allerdings nicht mit "quiet" os.execute zu tun, sondern liegt an Win 10, das "erstmal Luft holt", bevor es etwas anzeigt. Da wird vieles verschluckt.


    Workaround "Registry Hack"


    Den Workaround aus meinem Eröffnungspost sollte man vergessen. Ich halte ihn insofern für "gefährlich", dass das Windows CMD Fenster nicht mehr sichtbar wird, wenn beim oben genannten Workaround was schief geht.



    Besserer Workaround "SciTE Menu Hack"


    Vor Monaten habe ich mich mit dem Thema schon beschäftigt, das aufblitzende CMD Fenster zu vermeiden. Damals hatte ich als beste Möglichkeit die hier gefunden, bei der temporär ein Menüpunkt im SciTE Tools Menü erstellt, der gewünschte Befehl mit der Win Shell ausgeführt (damit ist der Explorer gemeint, wenn ich mich richtig erinnere) und der tomporäre Menüpunkt wieder auf seinen Ausgangszustand gesetzt wird.


    Neil Hodgson war nicht so toll begeistert davon, hatte aber auch nichts einzuwenden, außer dass das in zukünfigen Versionen vielleicht nicht mehr funktioniert. Aber das ist ja mit "luaL_register" auch nichts anderes. Du kannst ausprobieren, ob es noch funktioniert und dir zusagt.


    Hier ein Quick&Dirty Script, das ich damals zusammengebastelt hatte. Da können Fehler drin sein, aber ich bin nicht mehr so in der Materie drin. Dazu braucht es entsprechende Einträge in der "SciTEStartup.lua" und der "SciTEUser.properties". Die hatte ich damls von dir und du weißt wahrscheinlich besser als ich, was benötigt wird.


    Aus meinen Notizen


    Falls es klappt, könnte es deine Arbeit erleichtern. :saint:

    • Offizieller Beitrag
    Zitat von Professor Bernd

    Muss man für "quiet" os.execute noch irgendwas einstellen?

    Oops, hatte ich vergessen - habe es im Post ergänzt.


    Ich werde mich mal langsam daran machen und eine eigene Version basteln. Wobei ich die originale SciTE-Version von Neil verwenden werde (dann habe ich immer alle aktuellen Möglichkeiten, sowie Neil etwas Neues veröffentlicht). Die erforderliche Umgebung aus Lua Tools stelle ich mir zusammen aus SciTE4AutoIt und SciTE-RU, sowie eigenen Tools.