<p>Mudlet gel appelant display() sur un conteneur réglable</p>

Créé le 10 janv. 2021  ·  13Commentaires  ·  Source: Mudlet/Mudlet

Bref résumé du problème

Mudlet se fige quelques secondes après avoir tapé la mauvaise commande

Étapes pour reproduire le problème

Chad, utilisateur de Discord, explique :

  1. donc si je fais un conteneur ajustable, appelé testContainer
    testContainer = Adjustable.Container:new({name = "ARS main window"})
  2. et je fais lua testContainer dans mon invite de commande
  3. il gèle mudlet et me donne ensuite une erreur de mémoire

Sortie d'erreur

[ERROR:] Objekt:<run lua code> Funktion:<Alias4>
        <not enough memory>

Informations supplémentaires, telles que la version Mudlet, le système d'exploitation et des idées sur la façon de résoudre/implémenter :

ce n'est pas seulement sur mon ordinateur portable de merde, ou juste 1 profil.
c'est sur mon ordinateur portable et mon PC (16 Go de RAM)
sur les nouveaux profils, les anciens profils
Mulet 4.10.1

bug high lua only

Tous les 13 commentaires

Ce comportement semble cohérent avec une récursion infinie se produisant dans le code Lua d' une manière ou d'une autre...

Étiquetant comme haut parce que c'est un mauvais comportement, nous nous attendons à ce que Mudlet fasse mieux ici.

Serait-il juste de marquer cela comme étant susceptible d'être un problème uniquement lua ?

Ce comportement semble cohérent avec une récursion infinie se produisant dans le code _Lua_ d'une manière ou d'une autre ...

Oui c'est la raison. Comme Geyser garde toujours une référence du parent dans le conteneur (myGeyserElement.container).
C'est un problème connu avec l'affichage et c'est aussi la raison pour laquelle le créateur de Geyser a créé la fonction Geyser.display (il y a 11 ans :eyes: ).
https://github.com/Mudlet/Mudlet/blob/d84f0b5b171370feb96db2f1950a3fd6dac1709f/src/mudlet-lua/lua/geyser/GeyserUtil.lua#L35
Ainsi, au lieu d'utiliser display, une solution de contournement serait d'utiliser Geyser.display.

Peut-on identifier un objet Geyser s'il en est donné un ? Pourrait faire en sorte que display() appelle automatiquement cette fonction dans ce cas.

Peut-être pouvons-nous aider l'affichage à ne plus jamais rencontrer ces boucles infinies ?
Par exemple, conservez une liste de toutes les tables déjà affichées et n'affichez pas à nouveau une deuxième version complète d'une.

Après avoir creusé un peu, j'ai découvert que prettywrite avait une sécurité intégrée contre les boucles infinies, mais cela échoue pour Geyser dans certains cas (je ne sais pas pourquoi)
par exemple:

test = {}
test[1] = test
display(test)

Ne provoquera pas de boucle infinie.

J'ai essayé de commenter https://github.com/Mudlet/Mudlet/blob/4042ac7600db8196b219b3ae43a977045d591fdd/src/mudlet-lua/lua/DebugTools.lua#L185 et cela semble fonctionner mais je ne sais pas si cela pourrait causer d'autres problèmes et pourquoi il était là en premier lieu.

Sans rapport, il semble qu'il y ait une amélioration pour un ordre de clé cohérent dont nous pourrions profiter : https://github.com/lunarmodules/Penlight/pull/293

Après avoir creusé plus loin, j'ai remarqué que le problème se produit principalement si des étiquettes imbriquées sont utilisées (le menu contextuel du conteneur ajustable utilise une étiquette imbriquée)
Personnellement, je pense toujours que commenter https://github.com/Mudlet/Mudlet/blob/4042ac7600db8196b219b3ae43a977045d591fdd/src/mudlet-lua/lua/DebugTools.lua#L185 est une solution viable au problème.

J'ai testé https://github.com/kikito/inspect.lua qui fait plus ou moins la même chose que prettywrite et ils résolvent ce problème de la même manière (comme ce serait le cas si la partie tables[t] était commentée) mais à la différence que chaque table dupliquée obtient un identifiant au lieu d'un <cycle> générique

J'ai également trouvé un problème similaire en utilisant le deuxième exemple d'étiquettes emboîtables du Wiki Geyser (celui avec 'mainlabel') https://wiki.mudlet.org/index.php?title=Manual:Geyser#Demo -> survolez le « Hover there part », puis utiliser lua display(Geyser) provoque toujours une erreur de débordement de pile (ne se produit pas si vous utilisez inspect)

Peut-être que passer de prettywrite à inspect est quelque chose à penser.

Nous n'avons pas de raison particulière de nous en tenir à l'un - si l'autre est meilleur, allons-y. Comment les deux se comparent-ils, pourriez-vous publier avant/après ?

concernant l'ordre cohérent des clés, pourrait simplement changer l'utilisation des paires en paires et il devrait gérer tout cela. C'est essentiellement tout ce que fait l'extrait de code lié, nous venons de l'abstraire pour l'utiliser n'importe où en tant que spairs.

Nous n'avons pas de raison particulière de nous en tenir à l'un - si l'autre est meilleur, allons-y. Comment les deux se comparent-ils, pourriez-vous publier avant/après ?

C'est à peu près la même chose mais je ne sais pas si c'est "mieux" au moins ça ne plante pas dans Geyser (ce qui le rend mieux à mon avis) ;)
je vais ouvrir un RP

Cette page vous a été utile?
0 / 5 - 0 notes