Lua - Grundkenntnisse

  • Tables habe ich so verstanden: Arrays mit Wertepaaren (key/value). Erinnert ein wenig an WSH Dictonaries.

    Daraus resultiert auch, dass Lua extrem davon profitiert, wenn Funktionen/Variablen explizit lokal deklariert werden.

    Meinst du damit, es ist besser ein Table lokal zu deklarieren? Z.B. in "MeinModul.lua" local MyMod = {}?

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

    • Offizieller Beitrag

    Meinst du damit, es ist besser ein Table lokal zu deklarieren? Z.B. in "MeinModul.lua" local MyMod = {}?

    Ja. Was du nicht als lokal deklariert hast, landet in _G, dem Globalen Table. Die Suche nach Variablen, Funktionen ist immer:

    - im aktuellen Chunk (Funktion oder do... end - Bereich)

    - im Skript

    - in eingebundenen Modulen

    und zum Schluß im Globalen Table. Somit werden lokale Deklarationen am Schnellsten gefunden.

    Du wirst in vielen Skripten z. B. die Lokalisierung nativer Funktionen finden. lokal string = string

    Das bringt wieder ein paar Millisekunden. ;)

  • Danke! :)

    Edit: BugFix   Bitnugger

    1. Wie heißen denn Lua-Dateien, in die man Funktionen schreibt, die dann in anderen Lua-Dateien mit "requiere" eingebunden werden, z.B. die Datei OHKfuncs.lua? Nennt man sie Module, Bibliotheken, oder ...? Und kann man die Lua-Dateien, die nicht zu diese Gruppen gehören alle "Scripts" nennen, oder gibt es weitere Unterscheidungen?

    Bis zu deiner Antwort nenne ich allgemeine Lua-Dateien "Scripts" und die Lua-Dateien, die man mit "require" einbindet nenne ich "Bibliotheken".

    2. Können Funktionen in anderen Lua-Scripts mit "requiere" benutzt werden, die in der eingebundenen Bibliothek mit "local" deklariert wurden? In der OHKfuncs.lua deklarierst du OHK = {} ohne "local" davor, somit also global. Da meine Lua-/SciTE-Kenntnisse derzeit wohl eher bescheiden sind, will ich mich da nicht auf Tests verlassen, da ich nicht weiß, warum etwas mal funktioniert und mal nicht. ;)

    Edit 2:

    3. Was ist der Unterschied zwischen requiere "MyModule", LoadLuaFile("MyModule.lua") und LoadUserLuaFile('MyModule.lua')?

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

    4 Mal editiert, zuletzt von Professor Bernd (8. Oktober 2020 um 18:54)

    • Offizieller Beitrag

    Wie heißen denn Lua-Dateien, in die man Funktionen schreibt, die dann in anderen Lua-Dateien mit "requiere" eingebunden werden

    Das kommt drauf an. Schreibst du ein Modul, dann ist es ein Modul. Schreibst du eine Library, dann ist es eine Library.

    Die Unterscheidung ist auf den ersten Blick nicht so deutlich.

    Eine Bibliothek stellt i.A. eine Funktionssammlung dar (OHKfuncs.lua ist eine Bibliothek mit dem Globalen Table OHK, auf das nach dem Laden aus allen Skripten zugegriffen werden kann). Die Funktionen können aber ebensogut einzeln in der Datei vorhanden sein (nicht in einem Table)

    Ein Modul ist an sich auch eine Bibliothek - aber mit einem Unterschied: Alle Funktionen werden in einem lokalen Table erstellt. Dieses Table wird dann am Ende der Datei exportiert:

    -- z.B. "MeinModul.lua"

    local MeinModul = {

    f1 = function() .... end,

    f2 = function() .... end,

    f3 = function() .... end,

    ...

    }

    return MeinModul

    Schau mal ins Modul-Tutorial.

    Können Funktionen in anderen Lua-Scripts mit "requiere" benutzt werden, die in der eingebundenen Bibliothek mit "local" deklariert wurden?

    Nur wenn sie als Modul erstellt wurden. Alles was lokal ist, kann in anderen Dateien nicht erkannt werden, wenn es nicht exportiert wird.

    Übrigens nicht unwichtig: Im Gegensatz zu AutoIt sind Schleifenvariablen auch lokal. Man braucht sie zwar nicht deklarieren, aber ausserhalb der Schleife existieren sie nicht mehr.

    Was ist der Unterschied zwischen requiere "MyModule", LoadLuaFile("MyModule.lua") und LoadUserLuaFile('MyModule.lua')?

    LoadLuaFile und LoadUserLuaFile machen beide dasselbe: dofile

    Die beiden Funktionen verwenden nur einen vordefinierten Pfad (bzw den Pfad als Zusatzparameter mit Default-Wert), sodass nur der Dateiname übergeben werden muss.

    LoadUserLuaFile hatte ich erstellt um damit direkt eigene Dateien nur mit Angabe des Dateinamens aus dem Lua.User.Scripts.Path zu laden.

    Der Unterschied zu require? - Lies selbst:


    Lua offers a higher-level function to load and run libraries, called require. Roughly, require does the same job as dofile, but with two important differences. First, require searches for the file in a path; second, require controls whether a file has already been run to avoid duplicating the work. Because of these features, require is the preferred function in Lua for loading libraries.

  • Nach diesen guten Erklärungen und interessanten Informationen muss ich mich wirklich beherschen, mich nicht gleich ganz draufzustürzen. Die Vorfreude ist groß! :thumbup:

    Dabei habe ich in den letzten Tagen mein PSPad-Projekt ein wenig vernachlässigt und es ruft nach mir. Deshalb kümmere ich mich erstmal darum, bevor ich mich ganz in SciTE verliere. ;)

    In den letzten Tagen habe ich mich auch viel über das Problem "Prozedureinsprungpunkt "luaL_register" wurde ... nicht gefunden" informiert. Das sollte man wohl angehen, denn wer weiß, wie lange der Workaround mit einer alten SciTE.exe funktioniert. Schon in alten Threads haben Jos v.d.Z., Melba23, und andere gerne betont, dass es nicht ratsam ist, alte und neue Versionen von Dateien zu mischen, die zu SciTE4AutoIt3 gehören.

    Ich hätte gut Lust, bei Neil Hodgson anzufragen, aber erst will ich meine aktuelle Arbeit weiter führen, bevor ich mich in was anderes stürze. Zudem habt ihr vielleicht einen besseren Draht und vorallem mehr Hintergrundwissen. :rock:Aus Threads wie z.B. "#2058 Default build on Linux has dynamic libraries disabled" lese ich, dass das Problem vorallem in Zusammenhang mit Linux gemeldet und mit "Status: closed-fixed" abgehakt wurden. Vielleicht nutzt es was, wenn man da mal wieder nachhakt.

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