Mudlet: Les utilisateurs Windows avec non-ASCII dans le chemin de fichier ne peuvent pas charger LuaGlobal

Windows est connu pour être étrange avec les noms de chemin - et les fonctions de fichier dans Lua doivent être alimentées avec les noms de chemin correctement barrés. Dans le code C ++, si nous n'utilisons pas de littéraux de chaîne brute C ++ 11 (et nous pouvons être obligés de ne pas gérer un bogue Qt avec QObject::tr( ... ) ) un seul / dans un nom de chemin codé en dur pour les systèmes nix doit être doublement échappé * à \\\\ s'il doit être envoyé à une fonction lua - la compilation C ++ supprime chaque \\ jusqu'à \ et la même chose se produit dans l'interpréteur lua.

En l'occurrence, ce chemin dans le message [ ERROR ] donne l'impression que le chemin à ajouter au nom LuaGlobal.lua fichier ./ par défaut de sorte qu'il était censé être dans le même répertoire que l'exécutable Mudlet - cependant pour * Doze qui au moins aurait dû être changé en .\\ ou plutôt .\\\\ dans le code source C ++!

Cela signifie également que je pense que la méthode statique QDir::nativeSeparators( ... ) ne fait PAS la bonne chose si nous écrivons un chemin / nom de fichier sous forme de chaîne brute dans le code C ++ qui va à introduire dans l'interpréteur Lua sous forme de chaîne.

Je ne suis pas sûr de comprendre vos commentaires ou s'ils étaient même dirigés vers moi .. :)

Voyez-vous une chance pour moi de résoudre ce problème, à moins de configurer un tout nouvel utilisateur à partir de zéro?

C'est plus une observation générale pour quiconque y jette un œil. Il devrait être possible de le réparer en regardant le (s) chemin (s) utilisé (s) pour charger le fichier LuaGlobel.lua, en particulier sur la plate-forme Windows. Je soupçonne que nous avons laissé que le système d'exploitation utilise une valeur par défaut - qui peut être "le même répertoire que l'exécutable" mais qui ne convient pas à cause du chemin non POSIX.

En regardant ce que je pense être la cause de ce problème:

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;
    }
}

Cela semble immédiatement un peu douteux car A à D sont tous faux pour Windows, par exemple A devrait être "..\\\\src\\\\mudlet-lua\\\\lua\\\\LuaGlobal.lua" mais les autres ont besoin de remplacements d'exécution de / à \\\\ in à la fois les chaînes littérales ET les variables incluses. L'erreur d'origine en haut du sujet est que LUA_DEFAULT_PATH est vide au moment de son utilisation sous Windows!

Rappelez-vous que si le débogage, le message à l'écran [ ERROR ] reproduira un chemin qui a traversé les deux, je pense que \\ à \ un-échappements devrait donc ressembler à un vrai, réel Chemin d'accès Windows à l'écran - qui serait \LuaGobal.lua dans le cas donné - ce qui est probablement également faux et aurait dû être .\LuaGobal.lua peut-être - donc LUA_DEFAULT_PATH aurait dû être .\\\\ place?

Lua sur Windows gère / comme un séparateur de répertoire très bien cependant.

Cela n'a pas été mon expérience quelque peu limitée - IIRC il y a un paramètre de configuration quelque part dans le truc lua qui contient un tableau de 4 caractères qui contient les paramètres compilés pour, entre autres, le caractère générique dans les noms de paquet et le séparateur de répertoire. Je me souviens de cela parce que lorsque j'ai corrigé la gestion (interne à) LuaGlobal.lua des chemins de fichiers Windows vs * nix dans le passé, j'ai utilisé une vérification, je pense que sur un index de tableau C dans le config char array pour '\\' ou '/' - même si je pense qu'une meilleure solution a été trouvée par la suite.

Ah, ha - oui - voir la variable package.config - c'est la chose, de la FAQ non officielle de Lua :

1.40 Problèmes de compatibilité entre Windows et Unix?

Ici, 'Unix' désigne tout système d'exploitation de type POSIX tel que Linux, Mac OS X, Solaris, etc.

package.config est une chaîne dont le premier «caractère» est le séparateur de répertoire; donc package.config:sub(1,1) est soit une barre oblique soit une barre oblique inverse. En règle générale, essayez de l'utiliser lors de la création de chemins.

Une grande différence entre les versions Windows et Unix est que le package.path par défaut est basé sur l'emplacement de l'exécutable Windows, alors que sous Unix, il est basé sur /usr/local/share/lua/5.1 . Il est donc plus facile de faire une installation utilisateur locale de Lua sur Windows, mais Lua respecte les variables d'environnement LUA_PATH et LUA_CPATH .

Lua dépend plus directement des bibliothèques d'exécution C du système que de la plupart des langages de script, vous devez donc apprécier les différences de plate-forme. Utilisez le spécificateur "rb" avec io.open si vous avez besoin d'une compatibilité avec les E / S binaires Windows. Attention à os.tmpname car il ne renvoie pas de chemin complet sous Windows (préfixe avec la valeur de la variable d'environnement TMP avec une barre oblique inverse en premier.) os.clock est implémenté très différemment sur Windows.

De même, os.time peut en fait planter Lua si des spécificateurs de format non compatibles sont passés. (Ce n'est plus un problème avec Lua 5.2, qui effectue d'abord des vérifications de cohérence.)

Pour le sous-système Windows GUI, os.execute peut être irritant, et io.popen ne fonctionnera tout simplement pas - des bibliothèques d'extension multiplateformes sont disponibles dans ce cas.

'en règle générale' - cela ne contredit pas le fait que / tant que séparateur de répertoire fonctionne très bien sur Windows dans Lua.

C'est juste que - pour certains, y compris moi-même, cela ne fonctionne pas - il se peut que je n'ai pas une installation lua préparée en suivant la recette normale citée (ou que j'ai une installation Cygwin également).

Je me demande - êtes-vous en train de confondre, par hasard, la gestion des séparateurs de répertoires par le sous-système lua (ou plutôt la partie package) - qui peuvent être configurés dans les deux sens (ou peut-être pour quelque chose d'autre entièrement, disons ' pour RISCOS apparemment!), Les shells Windows cmd ou Powerline qui accepteront les deux ou le noyau Qt C ++ qui gérera également les deux?

Cela me déroute complètement quant à ce qui est censé fonctionner pour une installation lua compilée sur une plate-forme Windows - ah, se pourrait-il que msys soit POSIX-ish mais mingw est Windowish?

Non, je ne le suis pas, et c'est aussi pourquoi utiliser / in LuaGlobal.lua fonctionne pour de nombreuses personnes sous Windows dans son état actuel ...

Les séparateurs de chemin ne sont pas le problème ici.

Donc, vraisemblablement, l'interpréteur lua dans le mingw de Qt est configuré correctement pour Windows, et il utilise le même liblua auquel l'application Mudlet est liée {ce n'est peut-être pas, je suppose, pour tout le monde}. Par exemple, luarocks fournit un interpréteur lua 5.1 qu'il peut utiliser si aucun autre n'est trouvé mais par le même jeton ~ it ~ ses bibliothèques peuvent être utilisées à la place.

💡 Ah, je me demande, @Kebap qu'est-ce que vous obtenez si vous essayez d'obtenir les valeurs de package.config sur cette configuration qui vous donne l'erreur? Pour moi sur la ligne de commande, par exemple, sur mon système en cours d'exécution:

[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> ~]$

Notez la première valeur / qui est le séparateur de répertoire courant qui sera utilisé lors du chargement des packages - comme le fichier LuaGlobal.lua ! Bien sûr, sans les scripts lua externes exécutés / disponibles, je ne me souviens pas s'il est possible d' exécuter des choses à partir de la "ligne de commande" dans Mudlet. Je vais essayer d'allumer mon ordinateur portable 'Doze plus tard et voir ce que je reçois sur celui-là ...

Bien sûr, je peux essayer:

On dirait qu'il y a une barre oblique arrière où vous avez eu une barre oblique

Je ne sais pas si je devrais essayer cela dans Mudlet, car vous semblez avoir utilisé une manière et un endroit différents ..?

Je pourrais créer un ou deux nouveaux utilisateurs, avec et sans caractères spéciaux, juste pour m'assurer que le nom d'utilisateur est vraiment le problème ici. Pensez-vous que cela soit utile?

Oui, veuillez essayer

Le mercredi 25 avril 2018, 18 h 48, Kebap, [email protected] a écrit:

Je pourrais créer un ou deux nouveaux utilisateurs, avec et sans caractères spéciaux,
juste pour s'assurer que le nom d'utilisateur est vraiment le problème ici. Penses-tu
C'est utile?

-
Vous recevez ceci parce que vous avez commenté.

Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Mudlet/Mudlet/issues/1616#issuecomment-384355980 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAGxjN9JHbiPCOgUf3u1u8jVg0KjDiSbks5tsKj3gaJpZM4TZAbQ
.

Autant que je puisse voir, le code essaie tous les emplacements suggérés pour les fichiers LuaGlobal.lua et atteint enfin celui où il essaie:

LUA_DEFAULT_PATH "/LuaGlobal.lua"

cependant, d'après le message d'erreur résultant, il semble que LUA_DEFAULT_PATH est une chaîne vide, le chemin utilisé est donc:

/LuaGlobal.lua

en supposant (et je ne suis toujours pas convaincu, mais ce n'est, espérons-le, que mon problème) que '/' EST un séparateur de répertoire utilisable où il est utilisé, cela signifie rechercher le fichier à la racine du système de fichiers - sur ceux POSIX qui sont littéralement la racine et sous Windows, c'est la racine du lecteur actuellement actif, probablement C:\ (ou C:/ : wink :) - si nous voulons vraiment que ce soit le répertoire de travail actuel, alors LUA_DEFAULT_PATH devrait être un seul caractère . et pas complètement vide - dans ce cas, le message d'erreur renverrait soit:

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

ou s'il renvoie le chemin complet, peut-être quelque chose comme:

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

peut être? 😮

Je vois que le message d'erreur de l'interpréteur lua est capturé dans un std::string et qu'il est envoyé à cTelnet::postMessage( ... ) via une conversion std::string::c_str() en a const char * mais comme le postMessage attend un QString cela devrait engager le constructeur QString :: QString (const char str) qui utilise le convertisseur QString::fromUtf8() donc les caractères non-ASCII * devraient passer en bon état ... 😌

\

lua print(package.config)

à partir de la ligne de commande du profil Mudlet, même avec l'erreur que vous obtenez.

C'est un peu spéculatif, mais en tant que correctif d'exécution, je me demande s'il est possible de faire quelque chose comme:

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

pour changer le séparateur en / - bien que vous souhaitiez peut-être changer le paramètre "séparateur de commande" dans les préférences afin qu'il ne divise pas ce qui précède au niveau de ; - et ensuite voir si vous pouvez "exécuter" le fichier LuaGlobal.lua manuellement? Oh, cela ne fournira pas de messages d'erreur de type [ ERROR ] si cela ne fonctionne pas. \

Erreur confirmée avec Mudlet 3.8.1 sous Win 8.1 avec nom d'utilisateur avec caractère spécial: ä.
Aucune erreur avec le nom d'utilisateur sans caractères spéciaux.

lua print(package.config) sans résultat visible
lua print('test') également sans résultat visible
lua alias est disponible, mais print ne semble pas
lua echo('test') fonctionne comme prévu

Ran lua package.config = "/;?!_"
Le journal des erreurs dit: ERROR:[string "Alias: run lua code"]:4: [string "package.config = "/"]:1: unfinished string near '<eof>'

Changement du séparateur de commande de; à autre chose

Ran lua package.config = "/;?!_"
OK je suppose? Résultat invisible

Ran lua run("./LuaGlobal.lua")
Le journal des erreurs dit: ERROR:[string "return run("./LuaGlobal.lua")"]:1: attempt to call global 'run' (a nil value)

Test avec include - même erreur.

lua require("./LuaGlobal.lua") - erreur intéressante:
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'

Juste pour être sûr lua require("/LuaGlobal.lua")
Le journal des erreurs dit:
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'

Étrange à propos de print ne fonctionnant pas - je pensais que c'était un lua intégré - mais:

lua echo(package.config)

devrait également fonctionner.

En regardant la sortie du premier type d'exemple de travail, la sortie d'erreur essaie de charger le fichier LuaGlobal.lua - voyons quels noms de fichiers et chemins sont essayés:

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

Je n'étais pas sûr de l'emplacement du fichier ces jours-ci, j'ai donc téléchargé et installé le binaire 3.8.1 et j'ai trouvé que le chemin utilisé est:

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

également avec cette version de Windows Installer, j'ai ce qui suit pour le package.config:

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

donc les chemins d'accès doivent utiliser \ pour que le gestionnaire de package fonctionne IMO. On ne sait toujours pas pourquoi différentes personnes obtiennent des choses différentes.

Edité: pour citer la liste des chemins avec "plutôt que"

La raison pour laquelle certains chemins sont mojibake et d'autres affichent correctement le nom d'utilisateur doit être parce qu'ils proviennent de sources différentes et que certains d'entre eux ne sont pas encore correctement capables de I18n - il serait utile que nous puissions les retrouver et les réparer par Mudlet 4.0 - mais ce ne sont peut-être pas ceux que nous contrôlons. Notez qu'il ne peut pas s'agir du code d'affichage ou des polices car les messages d'erreur individuels passent tous par le même processus qu'ils ont été créés.

Juste pour être sûr que j'utilisais l'instance attendue (en tant que développeur, j'ai plus d'une copie sur ce PC), j'ai renommé le fichier et j'ai obtenu le même résultat:

J'ai également créé un nouvel utilisateur AVEC des caractères non ASCII (et probablement même pas Latin1 / ISO 885901) et je peux confirmer que les choses sont gâchées de la même manière pour cet utilisateur - Mudlet ne peut pas voir le fichier dans:

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

mais ça peut pour

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

:sanglot:

Ce Q&A sur Stack Exchange ne semble pas prometteur.

Cependant, le traducteur de nom de fichier luawinfile Windows sous licence MIT (compile uniquement sur mingw PAS MSVC) (convertit les noms de fichiers UTF-8 vers / à partir de l'UTF-16 qui doit être utilisé avec l'API de gestion de fichiers Windows) semble un peu mieux - il fournit des remplacements pour le module LFS qui peut prendre des noms de fichier et de chemin UTF-8.

Bonne trouvaille. Juste pour le lancer, nous avons déjà https://github.com/starwing/luautf8 dans Mudlet, y a-t-il quelque chose dans ce qui pourrait nous aider?

SlySven, votre liste de 15 noms de répertoires semble erronée. Par exemple, 13 doit lire .\.dll et non ..dll

Ah, c'est le système de balisage qui interfère - dans certains contextes ici, une barre oblique inverse échappe le caractère suivant qui est nécessaire, par exemple si vous voulez afficher un symbole inférieur à dans un texte ordinaire comme celui-ci "\ <", vous ne verrez pas le barre oblique inverse là-bas ... et j'avais utilisé des guillemets ordinaires simples plutôt que les guillemets de code - modifiés pour corriger les guillemets.

Le luautf8 concerne la gestion des chaînes UTF-8 - Je ne pense pas que cela aidera ici car luainfile concerne spécifiquement l'interfaçage avec la gestion des fichiers Windows (qui ne fonctionne qu'avec les chaînes UTF-16) Bibliothèque C ou plus probablement C ++ - il semble qu'elle doive soit boucler soit remplacer lfs sous Windows uniquement (pas Cygwin cependant, je parie) ...

Hmm mais nous n'utilisons pas lfs pour charger LuaGlobal.lua , alors comment luainfile résoudra-t-il le problème?

Ce n'est pas seulement un remplacement pour lfs . Il a également un remplacement pour dofile et loadfile . Nous devrons probablement remplacer notre appel à luaL_dofile par un appel lua à dofile .

Modifier pour ajouter: Les liens de la bibliothèque luainfile (par défaut) contre lua 5.3 ... Je ne sais pas si c'est une dépendance dure ou non.

On dirait que nous pouvons simplement écrire notre propre fonction luaL_dofile alors qui fonctionne avec l'encodage spécial de Windows?

Comment pouvons-nous faire avancer cela?

J'ai soulevé un problème sur le référentiel luawinfile concernant la compatibilité 5.1, mais j'ai jeté un coup d'œil et il utilise en fait des fonctionnalités de langage 5.3 qui ne sont pas fournies par lua 5.1 - il existe un module de compatibilité 5.3 officiel distinct qui tente de fournir certaines des fonctionnalités manquantes de 5.2 et 5.1, mais ce n'est pas sans quelques autres complications, ce n'est donc pas une goutte de solution.

Semble lié à # 229

Comment pouvons-nous faire avancer cela?

Nous aurons besoin de rétroporter la licence MIT https://github.com/cloudwu/luawinfile (un seul fichier C d'environ 884 lignes {808 soc} de code) de 5.3 à 5.1 pour accueillir certaines fonctionnalités qui ne sont pas présentes dans la version précédente. version de lua que Mudlet utilise. Cela nécessitera quelqu'un avec une meilleure compréhension du codage lua-C que je ne le pense actuellement, je pense. Cependant, cela semble être quelque chose qui peut être fait et testé indépendamment sans trop se soucier du reste de la base de code - bien qu'il ne puisse vraiment être testé que sur une plate-forme de développement Windows.

L'autre problème est que les gens ne peuvent pas enregistrer leurs profils sur des fenêtres avec des noms d'utilisateur non anglais - aucun historique n'est écrit. Ne pensez pas que nous avons un ticket pour ça.

@SlySven
Avez-vous peut-être appris certaines choses lors de vos récents correctifs pour envoyer des lettres internationales à Mudlet, pour faire avancer ce problème?

Pas vraiment, je pense que le back-portage de luawinfile vers Lua 5.1 offre notre meilleur espoir, mais je n'ai tout simplement pas une assez bonne compréhension (encore?) C/C++ + lua API pour me fier à ma capacité à le faire. Quelqu'un d'autre? Je suppose que nous devons examiner le code de la bibliothèque officielle Lua io et voir comment luawinfile remplace certaines (toutes, je ne sais pas?) Des fonctions par des remplacements spécifiques à Windows.

Comme les gens l'ont peut-être remarqué, ma plate-forme de développement Windows principale n'est pas la plus conforme (un ordinateur portable Windows 7 avec un processeur 64 bits mais exécutant la version 32 bits) - mon ordinateur principal dispose également d'un Windows 7 64 bits mais ce triple- la machine de démarrage n'a pas exécuter ce système d' exploitation depuis des mois , donc j'ai plusieurs heures de regarder un « Mise à jour de Windows ... ne pas éteindre » écran pour regarder avec impatience et je ne suis pas motivé, distributeur automatique!

Bien que, maintenant que le programme d'installation en ligne de Qt semble finalement être passé à n'offrir qu'une installation Windows 64 bits Mingw64 - par rapport à la précédente version 32 bits uniquement Mingw, je pourrais envisager de le faire si j'ai quelques heures à jeter. ..

Ça a l'air bien ...

C'est grâce à https://gist.github.com/Egor-Skriptunoff/2458547aa3b9210a8b5f686ac08ecbf0 qui a été créé en début d'année.

Sera disponible dans Mudlet 3.22