Mudlet: Windows-Benutzer mit Nicht-ASCII im Dateipfad können LuaGlobal nicht laden

Es ist bekannt, dass Windows mit Pfadnamen ungerade ist - und die Dateifunktionen in Lua müssen mit den korrekt durchgestrichenen Pfadnamen gespeist werden. Wenn wir im C ++ - Code keine C ++ 11-Rohzeichenfolgenliterale verwenden (und wir möglicherweise gezwungen sind, einen Qt-Fehler mit QObject::tr( ... ) ), wird ein einzelnes / in einem fest codierten Pfadnamen für nix-Systeme muss doppelt maskiert werden * auf \\\\ wenn es an eine Lua-Funktion gesendet werden soll - die C ++ - Kompilierung entfernt jeweils \\ bis zu \ und das gleiche passiert im Lua-Interpreter.

Zufällig sieht dieser Pfad in der Nachricht [ ERROR ] aus, als ob der Pfad zum Voranstellen des Dateinamens LuaGlobal.lua als Standard ./ belassen wurde, sodass erwartet wurde, dass er in der Nachricht .\\ oder besser .\\\\ geändert werden sollte!

Dies bedeutet auch, dass ich denke, dass die statische Methode QDir::nativeSeparators( ... ) NICHT das Richtige tut, wenn wir einen Pfad- / Dateinamen als Rohzeichenfolge in den laufenden C ++ - Code schreiben als Saite in den Lua-Interpreter eingespeist werden.

Ich bin mir nicht sicher, ob ich deine Kommentare verstehe oder ob sie überhaupt an mich gerichtet waren .. :)

Sehen Sie eine Chance, dass ich dieses Problem behebe, ohne einen ganz neuen Benutzer von Grund auf neu zu konfigurieren?

Es ist eher eine allgemeine Beobachtung für jeden, der es sich ansieht. Es sollte möglich sein, das Problem zu beheben, indem Sie sich die Pfade ansehen, die zum Laden der Datei LuaGlobel.lua verwendet werden, insbesondere auf der Windows-Plattform. Ich habe den Verdacht, dass wir das Betriebssystem verlassen haben, um einen Standardwert zu verwenden - der möglicherweise "dasselbe Verzeichnis wie die ausführbare Datei" ist, aber aufgrund des Nicht-POSIX-Pfads nicht geeignet ist.

Wenn ich mir anschaue, was meiner Meinung nach die Ursache für dieses Problem ist:

void TLuaInterpreter::loadGlobal()
{
#if defined(Q_OS_MACOS)
    // Load relatively to MacOS inside Resources when we're in a .app bundle,
    // as mudlet-lua always gets copied in by the build script into the bundle
    QString path = QCoreApplication::applicationDirPath() + "/../Resources/mudlet-lua/lua/LuaGlobal.lua";
#else
    // Additional "../src/" allows location of lua code when object code is in a
    // directory alongside src directory as occurs using Qt Creator "Shadow Builds"
    QString path = "../src/mudlet-lua/lua/LuaGlobal.lua"; // <== A
#endif

    int error = luaL_dofile(pGlobalLua, path.toUtf8().constData());
    if (error != 0) {
        // For the installer we do not go down a level to search for this. So
        // we check again for the user case of a windows install.

        // overload previous behaviour to check by absolute path as well
        // TODO this sould be cleaned up and refactored to just use an array and a for loop
        path = QCoreApplication::applicationDirPath() + "/mudlet-lua/lua/LuaGlobal.lua"; // <== B
        if (!QFileInfo::exists(path)) {
            path = "mudlet-lua/lua/LuaGlobal.lua"; // <== C
        }
        error = luaL_dofile(pGlobalLua, path.toUtf8().constData());
        if (error == 0) {
            mpHost->postMessage("[  OK  ]  - Mudlet-lua API & Geyser Layout manager loaded.");
            return;
        }
    } else {
        mpHost->postMessage("[  OK  ]  - Mudlet-lua API & Geyser Layout manager loaded.");
        return;
    }

    // Finally try loading from LUA_DEFAULT_PATH
    path = LUA_DEFAULT_PATH "/LuaGlobal.lua"; // <== D
    error = luaL_dofile(pGlobalLua, path.toUtf8().constData());
    if (error != 0) {
        string e = "no error message available from Lua";
        if (lua_isstring(pGlobalLua, -1)) {
            e = "[ ERROR ] - LuaGlobal.lua compile error - please report!\n"
                "Error from Lua: ";
            e += lua_tostring(pGlobalLua, -1);
        }
        mpHost->postMessage(e.c_str());
    } else {
        mpHost->postMessage("[  OK  ]  - Mudlet-lua API & Geyser Layout manager loaded.");
        return;
    }
}

Dies scheint sofort etwas zwielichtig zu sein, da A bis D für Windows alle falsch sind, zum Beispiel sollte A "..\\\\src\\\\mudlet-lua\\\\lua\\\\LuaGlobal.lua" aber die anderen müssen zur Laufzeit von / bis \\\\ in ersetzt werden sowohl die Literalzeichenfolgen als auch die enthaltenen Variablen. Der ursprüngliche Fehler oben im Thema ist, dass LUA_DEFAULT_PATH zum Zeitpunkt der Verwendung unter Windows leer ist!

Denken Sie daran, wenn Sie dies debuggen, reproduziert die Meldung [ ERROR ] auf dem Bildschirm einen Pfad, der beide durchlaufen hat. Ich denke, \\ bis \ Un-Escapings sollten also wie eine richtige, echte aussehen Windows - Pfad auf dem Bildschirm - das wäre \LuaGobal.lua in den Fall gegeben - was wahrscheinlich ist auch falsch und sollte gewesen .\LuaGobal.lua vielleicht - so LUA_DEFAULT_PATH hätte sein sollen .\\\\ stattdessen?

Lua unter Windows behandelt / als Verzeichnis-Trennzeichen.

Das war nicht meine etwas eingeschränkte Erfahrung - IIRC gibt es irgendwo im Lua-Material eine Konfigurationseinstellung, die ein 4-Zeichen-Array enthält, das die kompilierten Einstellungen enthält, unter anderem für das Platzhalterzeichen in Paketnamen und das Verzeichnis-Trennzeichen. Ich erinnere mich an das , weil , wenn ich festgelegt auf den (internen) LuaGlobal.lua von Windows Umgang vs. * nix - Dateipfade in der Vergangenheit hat mich auf einen Scheck verwenden, ich denke an einem C - Array - Index in den config char Array für '\\' oder '/' - obwohl ich denke, dass später eine bessere Lösung gefunden wurde.

Ah, ha - ja - siehe die Variable package.config - das ist die Sache aus den inoffiziellen Lua-FAQ :

1.40 Kompatibilitätsprobleme zwischen Windows und Unix?

Hier steht "Unix" für jedes POSIX-ähnliche Betriebssystem wie Linux, Mac OS X, Solaris usw.

package.config ist eine Zeichenfolge, bei der das erste 'Zeichen' das Verzeichnistrennzeichen ist. package.config:sub(1,1) ist also entweder ein Schrägstrich oder ein Backslash. Versuchen Sie in der Regel, dies beim Erstellen von Pfaden zu verwenden.

Ein großer Unterschied zwischen den Windows- und Unix-Builds besteht darin, dass der Standardpfad package.path auf dem Speicherort der ausführbaren Windows-Datei basiert, während er unter Unix auf /usr/local/share/lua/5.1 basiert. Es ist daher einfacher, eine lokale Benutzerinstallation von Lua unter Windows durchzuführen, aber Lua respektiert die Umgebungsvariablen LUA_PATH und LUA_CPATH .

Lua hängt direkter von den C-Laufzeitbibliotheken des Systems ab als die meisten Skriptsprachen, sodass Sie die Plattformunterschiede berücksichtigen müssen. Verwenden Sie den Bezeichner "rb" mit io.open wenn Sie Kompatibilität mit Windows-Binär-E / A benötigen. Seien Sie vorsichtig mit os.tmpname da unter Windows kein vollständiger Pfad zurückgegeben wird (Präfix mit dem Wert der Umgebungsvariablen TMP zusammen mit einem Backslash zuerst). os.clock ist sehr implementiert anders unter Windows.

Ebenso kann os.time Lua tatsächlich zum Absturz bringen, wenn nicht kompatible Formatspezifizierer übergeben werden. (Dies ist kein Problem mehr mit Lua 5.2, das zuerst die Überprüfung der geistigen Gesundheit durchführt.)

Für das Windows-GUI-Subsystem kann os.execute irritierend sein, und io.popen funktioniert einfach nicht - in diesem Fall sind plattformübergreifende Erweiterungsbibliotheken verfügbar.

'als allgemeine Regel' - das widerspricht nicht der Tatsache, dass / als Verzeichnis-Trennzeichen unter Windows in Lua einwandfrei funktioniert.

Das ist genau das - für einige, auch für mich, das nicht funktioniert - kann es gut sein, dass ich keine Lua-Installation habe, die nach dem normalen Rezept vorbereitet wurde (oder dass ich auch eine Cygwin-Installation habe).

Ich frage mich - verwirren Sie, durch Zufall, das die lua - Subsystem (oder vielmehr das Paket einen Teil davon) von Verzeichnistrenn Handhabung - die so oder so konfiguriert werden können (oder vielleicht etwas ganz anderes für sagen ' für RISCOS anscheinend!), Die Windows-Cmd- oder Powerline-Shells, die beide akzeptieren, oder der Qt C ++ - Kern, der auch beide unterstützt?

Es verwirrt mich zum Teufel, was für eine Lua-Installation funktionieren soll, die auf einer Windows-Plattform kompiliert wurde - ah, könnte es sein, dass msys POSIX-ish ist, aber mingw Windowish?

Nein, bin ich nicht, und es ist auch der Grund, warum die Verwendung von / in LuaGlobal.lua für viele Windows-Benutzer im aktuellen Zustand funktioniert ...

Pfadtrennzeichen sind hier nicht das Problem.

Vermutlich ist der Lua-Interpreter im Mingw von Qt für Windows korrekt konfiguriert und verwendet denselben Liblua, mit dem die Mudlet-Anwendung verknüpft wird (möglicherweise nicht für alle). Zum Beispiel stellt luarocks einen lua 5.1-Interpreter zur Verfügung, den es verwenden kann, wenn kein anderer gefunden wird, aber aus dem gleichen Grund ~ it ~ seine Bibliotheken verwendet.

💡 Ah, ich frage mich, @Kebap, was bekommen Sie, wenn Sie versuchen, die Werte von package.config in diesem Setup zu erhalten, das Ihnen den Fehler gibt? Für mich in der Kommandozeile zum Beispiel auf meinem aktuell laufenden System:

[stephen<strong i="11">@ripley</strong> ~]$ lua51
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print(package.config)
/
;
?
!
-
> ^D
[stephen<strong i="12">@ripley</strong> ~]$

Beachten Sie den ersten Wert / der das aktuelle Verzeichnis-Trennzeichen ist, das beim Laden von Paketen verwendet wird - wie die Datei LuaGlobal.lua ! Natürlich ohne die externe lua Skripte laufen / verfügbar I ist nicht mehr , ob es möglich ist , Dinge aus der „Befehlszeile“ in Mudlet zu laufen. Ich werde später versuchen, meinen 'Doze-Laptop zu starten und sehen, was ich auf diesem bekomme ...

Sicher kann man versuchen:

Es scheint, als gäbe es einen Schrägstrich, bei dem Sie einen Schrägstrich hatten

Sie sind sich nicht sicher, ob ich das in Mudlet versuchen soll, da Sie anscheinend eine andere Art und Weise und einen anderen Ort verwendet haben.

Ich könnte einen oder zwei neue Benutzer mit und ohne Sonderzeichen erstellen, um sicherzustellen, dass der Benutzername hier wirklich das Problem ist. Findest du es hilfreich?

Ja, bitte versuchen Sie es

Am Mittwoch, 25. April 2018, 18:48 Uhr schrieb Kebap, [email protected] :

Ich könnte einen oder zwei neue Benutzer mit und ohne Sonderzeichen erstellen.
Nur um sicherzugehen, dass der Benutzername hier wirklich das Problem ist. Denkst du
es ist hilfreich?

- -
Sie erhalten dies, weil Sie kommentiert haben.

Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Mudlet/Mudlet/issues/1616#issuecomment-384355980 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AAGxjN9JHbiPCOgUf3u1u8jVg0KjDiSbks5tsKj3gaJpZM4TZAbQ
.

Soweit ich sehen kann, versucht der Code alle vorgeschlagenen Speicherorte für die LuaGlobal.lua -Dateien und erreicht schließlich den Speicherort, an dem er versucht:

LUA_DEFAULT_PATH "/LuaGlobal.lua"

Aus der resultierenden Fehlermeldung geht jedoch hervor, dass LUA_DEFAULT_PATH eine leere Zeichenfolge ist. Der verwendete Pfad lautet also:

/LuaGlobal.lua

Unter der Annahme (und ich bin immer noch nicht überzeugt, aber das ist hoffentlich nur mein Problem), dass '/' ein funktionsfähiges Verzeichnis-Trennzeichen ist, in dem es verwendet wird, bedeutet dies, dass Sie nach der Datei im Stammverzeichnis des Dateisystems suchen - auf POSIX-Dateien buchstäblich das Stammverzeichnis und unter Windows ist es das Stammverzeichnis auf dem derzeit aktiven Laufwerk, wahrscheinlich C:\ (oder C:/ : wink :) - wenn wir wirklich wollen, dass es das aktuelle Arbeitsverzeichnis ist, dann LUA_DEFAULT_PATH sollte ein einzelnes . Zeichen sein und nicht vollständig leer - in diesem Fall würde die Fehlermeldung entweder Folgendes zurückgeben:

... cannot open ./LuaGlobal.lua ...

oder wenn es den vollständigen Pfad zurückgibt, möglicherweise so etwas wie:

... cannot open C:/Users/Eingeschränkt/AppData/Local/Mudlet/LuaGlobal.lua ...

kann sein? 😮

Ich sehe, dass die Fehlermeldung vom Lua-Interpreter in einem std::string erfasst und über eine std::string::c_str() Konvertierung an cTelnet::postMessage( ... ) gesendet wird ein const char * aber da der postMessage einen QString erwartet, sollte dies den Konstruktor QString :: QString (const char str) aktivieren , der den QString::fromUtf8() Nicht-ASCII-Zeichen * sollten unbeschädigt durchkommen ... 😌

\.

lua print(package.config)

über die Befehlszeile des Mudlet-Profils, auch wenn der Fehler angezeigt wird.

Dies ist ein wenig spekulativ, aber als Laufzeitfix frage ich mich, ob es möglich ist, etwas zu tun wie:

lua package.config = "/;?!_"

um das Trennzeichen in / zu ändern - obwohl Sie möglicherweise die Einstellung "Befehlstrennzeichen" in den Einstellungen ändern möchten, damit die oben genannten nicht bei ; - und dann prüfen, ob Sie können Die LuaGlobal.lua Datei manuell "ausführen"? Oh, das wird keine Fehlermeldungen vom Typ [ ERROR ] liefern, wenn es nicht funktioniert. \.

Bestätigter Fehler mit Mudlet 3.8.1 unter Win 8.1 mit Benutzername mit Sonderzeichen: ä.
Kein Fehler mit Benutzername ohne Sonderzeichen.

lua print(package.config) ohne sichtbares Ergebnis
lua print('test') auch ohne sichtbares Ergebnis
lua Alias ​​ist verfügbar, aber print scheint nicht zu sein
lua echo('test') funktioniert wie erwartet

Ran lua package.config = "/;?!_"
Das Fehlerprotokoll lautet: ERROR:[string "Alias: run lua code"]:4: [string "package.config = "/"]:1: unfinished string near '<eof>'

Befehlstrenner geändert von; zu etwas anderem

Ran lua package.config = "/;?!_"
OK, denke ich? Ergebnis unsichtbar

Ran lua run("./LuaGlobal.lua")
Das Fehlerprotokoll lautet: ERROR:[string "return run("./LuaGlobal.lua")"]:1: attempt to call global 'run' (a nil value)

Test mit include - gleicher Fehler.

lua require("./LuaGlobal.lua") - interessanter Fehler:
ERROR:[string "return require("./LuaGlobal.lua")"]:1: module './LuaGlobal.lua' not found: no field package.preload['./LuaGlobal.lua'] no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua\init.lua' no file '.\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua' no file '.\\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\' no file '.\.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll'

Nur um sicher zu gehen, lua require("/LuaGlobal.lua")
Das Fehlerprotokoll lautet:
ERROR:[string "return require("/LuaGlobal.lua")"]:1: module '/LuaGlobal.lua' not found: no field package.preload['/LuaGlobal.lua'] no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal\lua\init.lua' no file '.\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal\lua.lua' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal\lua\init.lua' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal\lua' no file '.\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal\lua.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll' no file 'C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\/LuaGlobal' no file '.\/LuaGlobal.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\/LuaGlobal.dll' no file 'C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll'

Seltsam, dass print nicht funktioniert - ich dachte, es wäre ein eingebauter Lua - aber:

lua echo(package.config)

sollte auch funktionieren.

Wenn Sie sich die Ausgabe des ersten Arbeitsbeispiels ansehen, versucht die Fehlerausgabe, die Datei LuaGlobal.lua zu laden. Sehen wir uns an, welche Dateinamen und Pfade versucht werden:

1. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua.lua
2. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua\init.lua
3. .\\/LuaGlobal\lua.lua
4. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua.lua
5. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\lua\\/LuaGlobal\lua\init.lua
6. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.lua
7. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua\init.lua
8. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\\/LuaGlobal\lua
9. .\\/LuaGlobal\lua.dll
10. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\\/LuaGlobal\lua.dll
11. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll
12. C:\Users\Eingeschränkt\.config\mudlet\profiles\new profile name\
13. .\.dll
14. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\.dll
15. C:\Users\Eingeschr�nkt\AppData\Local\Mudlet\app-3.8.1\loadall.dll

Ich war mir nicht sicher, wo sich die Datei in diesen Tagen befinden sollte, also habe ich die 3.8.1-Binärdatei heruntergeladen und installiert und festgestellt, dass der verwendete Pfad wie folgt lautet:

C: \ Benutzer \ Stephen \ AppDataLocal \ Mudlet \ app-3.8.1 \ mudlet-lualua

Auch mit dieser Windows Installer-Version habe ich Folgendes für die package.config:

lua print(package.config)
\
;
?
!
-

Daher müssen Pfade dazu \ damit der Pakethandler IMO funktioniert. Es ist jedoch immer noch nicht klar, warum verschiedene Menschen unterschiedliche Dinge bekommen.

Bearbeitet: um die Liste der Pfade mit "anstatt" zu zitieren

Warum einige Pfade Mojibake sind und andere den Benutzernamen korrekt anzeigen, muss daran liegen, dass sie aus verschiedenen Quellen stammen und einige von ihnen noch nicht richtig I18n-fähig sind - es wäre hilfreich, wenn wir diese aufspüren und mit Mudlet 4.0 beheben könnten - aber Sie sind möglicherweise nicht diejenigen, über die wir die Kontrolle haben. Beachten Sie, dass es sich nicht um den Anzeigecode oder die Schriftarten handeln kann, da die einzelnen Fehlermeldungen alle denselben Prozess durchlaufen, den sie erstellt haben.

Um sicherzugehen, dass ich die erwartete Instanz verwendet habe (als Entwickler habe ich mehr als eine Kopie auf diesem PC), habe ich die Datei umbenannt und das gleiche Ergebnis erhalten:

Außerdem habe ich einen neuen Benutzer mit Nicht-ASCII-Zeichen (und wahrscheinlich nicht einmal Latin1 / ISO 885901) erstellt und kann bestätigen, dass die Dinge für diesen Benutzer auf die gleiche Weise durcheinander gebracht wurden - Mudlet kann die Datei nicht sehen in:

C:\Users\şțȅƥĥēƞ\AppData\Local\Mudlet\app-3.8.1\mudlet-lua\lua\LuaGlobal.lua

aber es kann für

C:\Users\stephen\AppData\Local\Mudlet\app-3.8.1\mudlet-lua\lua\LuaGlobal.lua

:Schluchzen:

Diese Fragen und Antworten zu Stack Exchange klingen nicht vielversprechend.

Der vom MIT lizenzierte luawinfile Windows-Dateinamenübersetzer (nur auf mingw NOT MSVC kompilieren) (konvertiert UTF-8-Dateinamen in / von UTF-16, der mit der Windows-API zur Dateiverwaltung verwendet werden muss ) sieht jedoch etwas besser aus - er bietet Ersatz für das LFS-Modul, das UTF-8-Datei- und Pfadnamen annehmen kann.

Guter Fund. Nur um es rauszuwerfen, wir haben https://github.com/starwing/luautf8 bereits in Mudlet. Gibt es irgendetwas in dem, was uns helfen könnte?

SlySven, Ihre Liste mit 15 Verzeichnisnamen scheint falsch zu sein. Zum Beispiel sollte 13 .\.dll und nicht ..dll lauten

Ah, das ist das störende Markup-System - in einigen Kontexten hier entgeht ein Backslash dem folgenden Zeichen, das benötigt wird, z. B. wenn Sie in einem normalen Text wie diesem "\ <" ein Symbol weniger als anzeigen möchten, wird das nicht angezeigt Backslash dort ... und ich hatte einzelne gewöhnliche Anführungszeichen anstelle der Code-Anführungszeichen verwendet - bearbeitet, um das Zitat zu korrigieren.

Bei luautf8 dreht sich alles um die Behandlung von UTF-8-Zeichenfolgen. Ich glaube nicht, dass dies hier hilfreich sein wird, da es bei luainfile speziell um die Schnittstelle zur Behandlung von Windows-Dateien geht (die nur mit UTF-16-Zeichenfolgen funktioniert ). C oder wahrscheinlicher C ++ - Bibliothek - es sieht so aus, als müsste sie entweder umlaufen oder lfs nur unter Windows ersetzen (allerdings nicht Cygwin, würde ich wetten) ...

Hmm, aber wir verwenden nicht lfs , um LuaGlobal.lua lfs zu laden. Wie wird also luainfile das Problem lösen?

Es ist nicht nur ein Ersatz für lfs . Es hat auch einen Ersatz für dofile und loadfile . Wir werden wahrscheinlich unseren Anruf auf luaL_dofile durch einen Lua-Anruf auf dofile ersetzen müssen.

Bearbeiten, um hinzuzufügen: Die luainfile -Bibliotheksverknüpfungen (standardmäßig) gegen lua 5.3 ... Ich bin mir nicht sicher, ob dies eine harte Abhängigkeit ist oder nicht.

Scheint, als könnten wir einfach unsere eigene luaL_dofile -Funktion schreiben, die dann mit der speziellen Windows-Codierung funktioniert?

Wie können wir das vorantreiben?

Ich habe ein Problem im luawinfile-Repository angesprochen, in dem nach der 5.1-Kompatibilität gefragt wurde, aber ich habe es mir angesehen und es werden tatsächlich einige 5.3-Sprachfunktionen verwendet, die nicht von lua 5.1 bereitgestellt werden. Es gibt ein separates, offizielles 5.3-Kompatibilitätsmodul , das versucht, diese bereitzustellen Einige der fehlenden Funktionen zu 5.2 und 5.1, aber es ist nicht ohne andere Komplikationen, so ist es kein Tropfen in der Lösung.

Scheint mit # 229 verwandt zu sein

Wie können wir das vorantreiben?

Wir müssen das MIT-lizenzierte https://github.com/cloudwu/luawinfile (eine einzelne C-Datei mit etwa 884 Codezeilen) von 5.3 auf 5.1 zurückportieren, um einige Funktionen zu berücksichtigen, die in früheren Versionen nicht vorhanden waren Version von Lua, die Mudlet verwendet. Dies erfordert jemanden, der die Lua-C-Codierung besser versteht als ich es derzeit denke, denke ich. Es scheint jedoch etwas zu sein, das unabhängig durchgeführt und getestet werden kann, ohne sich über den Rest der Codebasis Gedanken zu machen - obwohl es nur auf einer Windows-Entwicklungsplattform wirklich getestet werden kann.

Das andere Problem ist, dass Benutzer ihre Profile nicht in Fenstern mit nicht englischen Benutzernamen speichern können - es wird kein Verlauf geschrieben. Denken Sie nicht, dass wir ein Ticket dafür haben.

@SlySven
Haben Sie vielleicht während Ihrer letzten Korrekturen einige Dinge gelernt, um internationale Briefe an Mudlet zu bringen, um dieses Problem voranzubringen?

Nicht wirklich, ich denke, dass die Rückportierung von luawinfile nach Lua 5.1 unsere beste Hoffnung bietet, aber ich habe (noch?) Nicht genug Verständnis für die C/C++ + lua API, um Vertrauen in meine Fähigkeit zu setzen, dies zu tun. Hat noch jemand? Ich denke, wir müssen den Code für die offizielle Lua io -Bibliothek durchsehen und sehen, wie luawinfile einige (alle, ich weiß nicht?) Funktionen durch Windows-spezifische Ersetzungen ersetzt.

Wie die Leute vielleicht bemerkt haben, ist meine primäre Windows-Entwicklungsplattform nicht die konformste (ein Windows 7-Laptop mit einem 64-Bit-Prozessor, aber mit der 32-Bit-Version) - mein Haupt-PC hat auch ein 64-Bit-Windows 7, aber dieses Triple- Die Boot-Maschine hat dieses Betriebssystem seit Monaten nicht mehr ausgeführt, daher habe ich mehrere Stunden Zeit, um auf einen Bildschirm "Windows aktualisieren ... nicht ausschalten" zu starren, auf den ich mich freuen kann, und ich bin nicht so motiviert, ATM!

Obwohl das Qt-Online-Installationsprogramm nun offenbar darauf umgestellt hat, nur eine 64-Bit-Mingw64-Windows-Installation anzubieten - im Vergleich zu der vorherigen 32-Bit-Mingw-Installation, die ich nur in Betracht ziehen könnte, könnte ich dies in Betracht ziehen, wenn ich einige Stunden Zeit zum Wegwerfen habe. ..

Gut aussehen...

Dies ist https://gist.github.com/Egor-Skriptunoff/2458547aa3b9210a8b5f686ac08ecbf0 zu verdanken, das zu Beginn des Jahres erstellt wurde.

Wird in Mudlet 3.22 verfügbar sein