Extension:Scribunto/We use Lua

Reciprocation page between Lua developers.

We are developers who use Lua to enhance templates, to optimize performance of the wiki servers and to offer a new experience to final users.

Use Lua, which technical parts of this tool, which functions and services to final users ?

Lua is a recent language, simple to read and write, but very complete. And in wikis limited and adapted.

Thanks to mediawiki developers who offer to us this language and these tools.

How to name this page ? Lua reciprocation, Lua metting of users, Developers community, Developers Lua reciprocation ?

And in the future : Project:Lua, Portal:Lua.

LUA inter modules

 * Il semble que LUA devrait savoir gérer des appels entre modules, récursifs avec gestion d'erreurs.
 * "Introduced a little bit of abstraction for modules that interface with PHP, so that we don't have to have all the code in one file." --Rical (d) 20 décembre 2012 à 17:54 (CET)


 * Je continue ici pour ne pas mettre du LUA partout. En cherchant pour ma table de paramètres multilingues arg_i18n, je vois les iterator que j'utilise, voir table_iterator, mais aussi le multitache, l'héritage objet et pour gérer les erreurs, les __index metamethod qui pourraient detecter les paramètres ou valeurs imprévus. --Rical (d) 19 janvier 2013 à 23:37 (CET)

Lua
Hello, toi qui semble avoir commencé à tester Lua/Scribunto depuis quelques temps j'ai une question si tu as le temps : peut-on faire des modules en sous-pages et les appeler ? Typiquement il me semblait opportun (comme dans toute programmation structurée) de séparer les diverses fonctions utilitaires dans des modules séparés. J'ai donc créé un module de test (Module:Taxobox-fr) et un module d'outils (Module:Taxobox-fr/outils). Mais j'ai échoué à importer ce dernier, alors qu'après renommage dans l'espace module (Module:Taxoboxoutils) ça a marché directement. C'est pas très grave mais ça me paraît plus "propre" d'avoir les fonctions utilitaires "sous" le module principal.

Cordialement, Hexasoft (discuter) 7 décembre 2012 à 19:14 (CET)
 * Je n'ai aucune expérience sur l'appel d'autres modules, mais ton expertise m'intéresse. J'ai vu hier ta question sur MW. Je me demande si /sous-page/Module:Foo fonctionnerait et serait appelable ? --Rical (d) 7 décembre 2012 à 19:28 (CET)
 * Marf ! Je pense que soit j'avais fumé du mauvais soit il y a eu un bug : j'ai réussi à utiliser l'appel à des fonctions qui sont dans un module distinct qui est dans une sous-page.
 * Voir mon test : http://test2.wikipedia.org/wiki/User:Hexasoft/test2, avec le module http://test2.wikipedia.org/wiki/Module:Mainmodule qui importe en premier lieu les fonctions de http://test2.wikipedia.org/wiki/Module:Mainmodulesub et en second lieu les fonctions de http://test2.wikipedia.org/wiki/Module:Mainmodule/sub.
 * Les deux inclusions de modules fonctionnent. Il est donc possible de ranger ses sous-modules dans des sous-pages du module principal, ce qui est quand même plus propre je pense (enfin, si les fonctions dans les sous-modules ne servent qu'au module principal).
 * Je compte commencer la rédaction d'un document (en français pour commencer, traduire en anglais ensuite) sur deux choses : les bonnes pratiques Lua (en terme de rédaction de code) ; les bonnes pratiques Scribunto (en terme de comment agir avec WP).
 * Ça peut sembler un peu prétentieux de rédiger un guide de bonnes pratiques (encore que je suis programmeur et enseignant de la programmation, je pense avoir des choses générales pertinentes à dire), mais à mon sens c'est plus pour créer les bases d'un document que d'autres pourront compléter et ajuster en fonction de ce qu'on apprend sur ce qui marche, ne marche pas, ou ce qui est plus (ou moins) efficace.
 * Qu'en pense-tu ?
 * Cordialement, Hexasoft (discuter) 7 décembre 2012 à 20:12 (CET)
 * Voici un premier jet : Utilisateur:Hexasoft/Lua. C'est assez "en vrac" pour le moment, il faudra structurer tout ça, et je ne parle pour le moment que de généralités. Il faudra sans doute une structuration plus poussées, peut-être avec des sous-pages pour ne pas alourdir la lecture. Il faudra aussi regrouper des liens vers les différentes documentations existantes (même si beaucoup me semble au mieux incomplète pour une vraie utilisation). Cordialement, Hexasoft (discuter) 7 décembre 2012 à 21:57 (CET)
 * Hello. En fait il y a un "bug" : si un module est en sous-page ses modifications ne sont pas vues/mises à jour. Donc avec la structure Module:toto qui utilise Module:toto/sub une modif de toto/sub reste invisible tant que tu ne modifies pas toto lui-même. J'ai signalé le problème aux développeurs.
 * Sinon je pense avoir pas mal complété Utilisateur:Hexasoft/Lua, même s'il faut maintenant surtout structurer un peu toutes ces sections. De mon coté je pense être prêt pour remplacer des modèles par ça ! Cordialement, Hexasoft (discuter) 11 décembre 2012 à 09:30 (CET)
 * Oui, c'est une bonne introduction au LUA, et surtout qui repère les points critiques. J'ai vu ce matin que la fonction ustring est en cours de révision pour y intégrer UTF8, mais seulement pour LuaStandalone pour le moment. Tu as bossé dur depuis des jours, mais j'ai trop de choses à faire ailleurs pour m'y coller vraiment. --Rical (d) 11 décembre 2012 à 10:25 (CET)

← Hello, en jetant un œil au code de Module:Author j'ai constaté que pour préparer des séries d'éléments texte successifs tu utilises la technique consistant à insérer dans une table puis à la fin à "applatir" le tout avec table.concat. Quels sont les avantages de cette technique, par rapport - par exemple - à concaténer au fur et à mesure dans un texte (avec "texte = texte .. 'data'") ? Est-ce que ça permet d'avoir une sortie triée (si oui ça n'a donc d'intérêt qu'au sein d'une liste homogène) ? Est-ce que c'est plus rapide que la concaténation au fur et à mesure ? Cordialement, Hexasoft (discuter) 7 janvier 2013 à 19:04 (CET) PS: il est vraiment dommage que Scribunto ne gère pas vraiment l'UTF8 dans les fonctions de chaînes comme string.sub par exemple...
 * Dans mon cas les 2 solutions, table ou texte me semblent équivalentes et je n'utilise pas le tri. Si la conversion des tables en texte est bien gérée, l'exécution devrait être plus rapide. J'ai aussi vu en de nombreux endroits que la vitesse d'exécution est une volonté permanente des développeurs des wikis. C'est même une des principales motivations de Scribunto et LUA. Si on peut les aider tant mieux.
 * En fait, quand j'ai commencé à travailler sur le modèle Auteur dans test2, User:Uncle G = w:fr:Utilisateur:Moti-v l'a vu et m'a proposé sa base de travail en anglais qui m'a parue bien structurée, bien que rudimentaire. Je l'ai donc gardée et adaptée au Modèle wikisource français. Dans ma page de test tu vois les 2. J'envisage même d'en faire un modèle multilingue, voir "local data_i18n" où le i18n rappelle les modules de traductions des extensions en javascript. --Rical (d) 7 janvier 2013 à 23:50 (CET)
 * Ok, merci pour ta réponse. De mon coté j'ai grosso modo terminé mon modèle de taxobox : quasiment toutes les fonctionnalités sont là, et quelques autres qui n'étaient pas possibles avant (comme les découpages intelligents de chaînes). J'ai aussi pas mal avancé le nettoyage du code et la séparation en sous-modules.
 * Je pense que je vais regarder maintenant du coté des fonctions d'analyse d'exécution pour essayer de regarder coté performances.
 * Cordialement, Hexasoft (discuter) 8 janvier 2013 à 00:26 (CET)
 * Bientôt UTF-8 : This is a reimplementation of Lua's string module with support for UTF-8. mais il faudra attendre le prochain déploiement ( vers le 17/1 ? ) --Rical (d) 9 janvier 2013 à 19:49 (CET)
 * Cool ! Au passage la version 1.21wmf7 va être déployé aujourd'hui sur en: et dans une semaine sur les autres WP. C'est normalement la version avec Lua donc il va sans doute être possible de migrer les tests de modules sur fr:, ce qui sera un peu plus friendly . Cordialement, Hexasoft (discuter) 9 janvier 2013 à 20:07 (CET)

Je fais une autre section, mais c'est toujours Lua :)
Hello, j'ai ajouté dans le code de mon module une vérification des paramètres, en ce sens que j'ai dans mon sous-module taxobox-data une liste de tous les paramètres reconnus, et je vérifie donc qu'on n'appelle pas le module/modèle avec des paramètres non référencés (ce qui m'a d'ailleurs permis de trouver un de mes articles où j'avais fait une faute de frappe ! ). Comme la table frame:getParent.args est une meta-table et non une table accéder à un champs pour la première fois est plus coûteux. Or avec ce mécanisme j'accède forcément à tous les paramètres présents (pour valider qu'ils existent) et donc la plupart du temps je fais plus d'accès que n'en a besoin le module, puisqu'on n'utilise pas souvent tous les paramètres possibles. As-tu une idée de l'éventuel sur-coût ? (bien que la fonctionnalité en elle-même me semble importante, mais il ne faudrait pas que ce soit à un sur-coût trop grand).

Plus généralement je trouve qu'il manque un peu de pages meta "actives" pour discuter et échanger autour des problèmes pratiques de programmation... Cordialement, Hexasoft (discuter) 11 janvier 2013 à 11:57 (CET)


 * De mon coté, j'ai ajouté une génération de documentation des paramètres (voir options et generDoc), et (dans ce cadre pour l'instant) une détection et un affichage rudimentaire d'erreurs. Je peux aussi lister quelques ou tous les paramètres, ou les limiter à ceux définis. Et même mettre la doc avant ou après, en ligne ou en colonne, ou changer la présentation ou les catégories selon la langue en ou fr.
 * Pour les doc des modèles aussi, j'utilise depuis longtemps l'option c=: pour afficher les catégories dans les doc au lieu de catégoriser directement. On peut utiliser ainsi plusieurs exemples d'un modèle dans la même page et voir à chaque fois quelles catégories il a généré. Voir catView.
 * En Edit de LUA, le "show preview" peut aussi tester le module sur la page que l'on veut. J'ai donc adapté le module pour pouvoir changer les options tout en restant en edit, voir optConsole, et comment il se combine aux options qui viennent du modèle.
 * Les modèles, exécutés en mode interprété, noyé par l'accumulation de parenthèses, sont un vrai gachi. Mais frame:getParent est déjà complètement en mémoire quand tu prends la main en LUA et cela a été fait en programmation objet php, donc très efficace. Le mécanisme ressemble à table_iterator dans mon module, et au niveau de l'exécution compilée le processeur parcourt des tables de pointeurs vers les différentes variables ou vers les éléments de chaque table, ou vers les paramètres d'appels de fonctions. En exécution de code objet compilé, quel que soit le langage, l'efficacité est à peu près la même. Les données ne bougent en mémoire que quand tu les modifies. Tu n'a donc pas de soucis à te faire pour l'efficacité.
 * Une seule vérification des quelques paramètres utilisés par rapport à tout ce que fait le module à chaque utilisation, c'est pas très lourd. Et c'est encore moins lourd si tu mets en tête de la liste des vérifications les paramètres statistiquement les plus utilisés.
 * Bref Lua est magique, il fait exploser nos possibilités et notre efficacité, même à notre insu. --Rical (d) 12 janvier 2013 à 02:38 (CET)
 * Hello,
 * pour les docs pour le moment le module ne donne que des fonctions qui permettent de faire un "dump" formaté des données (qui sont dans un module séparé dans mon cas), il faudrait effectivement que j'ajoute une table expliquant les paramètres.
 * Pour ce qui est des catégories j'ai fait le choix de les inclure seulement quand on est dans l'espace article (par contre je vais modifier le code pour les afficher (sans les inclure) dans les autres cas, c'est effectivement plus pertinent).
 * De mon coté je ne me préoccupe pas trop des autres langues car en biologie nous n'avons pas les mêmes approches sur fr: et (par exemple) sur en: ça serait un peu trop compliqué de tout prendre en compte (sans compter que nous ne sommes pas d'accord avec certain de leurs choix ).
 * Coté gestion d'erreur j'ai une fonction qui génère une "box" d'erreur (rouge, pour bien la voir) avec un message générique puis une indication de la cause de l'erreur + une catégorie d'erreur. Je trouve ça assez puissant de pouvoir stopper le code quand on rencontre l'erreur et de pouvoir informer le rédacteur directement qu'il y a un problème, et lequel !
 * Note : c'est curieux, sur la page de la roadmap de la version de mediawiki utilisée sur test2 ils indiquent que en: est terminé (et le 14 de ce mois pour les autres langues). Mais quand je vais sur en: l'espace Module: n'est pas connu ! Est-ce que les modules demandent une activation spécifique sur chaque wiki ? Cordialement, Hexasoft (discuter) 12 janvier 2013 à 11:45 (CET)
 * Pour le déploiement de scribunto, il n'est pas toujours synchrone avec MW comme tu peux le voir dans mon suivi. C'est peut-être à cause de bugs résiduels à voir dans les liens de "See also" juste en dessous. --Rical (d) 12 janvier 2013 à 17:56 (CET)

Others

 * http://test2.wikipedia.org/wiki/Special:RecentChanges
 * (diff | hist) . . Module talk:Taxobox-fr‎; 11:30:29 . . (+179)‎ . . ‎Hexasoft (Talk | contribs)‎ (→‎TO DO: )
 * http://test2.wikipedia.org/wiki/User:Uploadwizardtest
 * (Upload log); 00:34:59 . . Uploadwizardtest (Talk | contribs) uploaded "File:0.18444785473492298.png" ‎(User created page with UploadWizard)
 * http://test2.wikipedia.org/wiki/0.5644693458351062
 * (diff | hist) . . N 0.5644693458351062‎; 00:32:18 . . (+33)‎ . . ‎65.50.209.8 (Talk)‎ (Created page with "Starting a new page using the URL")
 * http://test2.wikipedia.org/wiki/Special:Log/course
 * (Education Program course log); 22:42:16 . . Vojtech.dostal (Talk | contribs) created course Křesťanství I ‎
 * http://test2.wikipedia.org/wiki/Module:Author
 * http://test2.wikipedia.org/wiki/Auteur:Arthur_Rimbaud
 * http://test2.wikipedia.org/wiki/Module:Author
 * http://test2.wikipedia.org/wiki/Auteur:Arthur_Rimbaud
 * http://test2.wikipedia.org/wiki/Auteur:Arthur_Rimbaud