Wikifunctions:Mise à jour/2024-11-01
| ◀ |  Mise à jour de l'état de Wikifunctions  |
▶ |
|
Réécriture du backend
L'équipe de la Wikipédia abstraite travaille à réécrire nos services backend dans un langage de programmation différent, probablement Rust. Node/JS nous a bien servi, mais nous avons rencontré des limites qui seraient mieux traitées en passant à un autre écosystème.
Le travail immédiat porte sur la façon dont nous pourrions mieux interagir avec WebAssembly (WASM). Il y a presque exactement un an, nous avons annoncé que nous allions commencer à exécuter du code Python et JS dans WASM pour ses caractéristiques de bac à sable. Depuis lors, nous avons interagi avec WASM via l'interface WebAssembly System Interface (WASI), qui permet aux commandes WASM d'avoir un accès sélectif au système d'exploitation sous-jacent.
Alors que WASI a rendu nos exécuteurs de code plus sûrs, l'utilisation de cet outil a causé des problèmes. Le nœud de l'outillage autour de WASI n'est pas particulièrement riche. Au moment de l'adoption, nous avons trouvé que notre meilleure option était d'utiliser les interfaces WASI en mode ligne de commande. Nous avons décidé d'exécuter ces interfaces dans des sous-processus. L'utilisation de sous-processus a entraîné des problèmes de stabilité du système, principalement liés à l'impossibilité de nettoyer ces sous-processus dans certaines conditions.
L'écosystème WASI sous Rust est beaucoup plus avancé. Plusieurs périodes d'exécution WASI fournissent des outils qui offrent de bons niveaux de contrôle sur la liaison des commandes WASM aux appels système. Avec ces outils, nous pouvons rationaliser notre utilisation de WASI. Nous pouvons lancer nos exécuteurs de code directement à l'intérieur du programme Rust hôte, éliminer les sous-processus, et ainsi éviter plusieurs sources d'instabilité du système. En plus, ce niveau de contrôle signifie que nous pouvons également améliorer notre bac à sable - une victoire en matière de sécurité - et, dans un avenir lointain (...ou peut être proche) coopter certains appels système pour mettre en œuvre de nouvelles fonctionnalités pour nos exécuteurs de code.
Prochain « coin des bénévoles » le 4 novembre
La semaine prochaine, lundi 4 novembre 2024, à 18h30 UTC, nous aurons notre coin mensuel des bénévoles. À moins que vous n'ayez beaucoup de questions, nous suivrons notre ordre du jour habituel, en donnant des mises à jour sur les plans à venir et les activités récentes, en disposant de beaucoup de temps et d'espace pour vos questions, et en construisant une fonction ensemble. Au plaisir de vous voir lundi !
Fonction de la semaine : langue d’un lexème
La fonction Z19295 est une fonction simple : elle prend un seul argument, un lexème, et renvoie la langue (naturelle) du lexème. Chaque lexème dans Wikidata appartient à une seule langue, par exemple si nous regardons le lexème L610505, mkpụrụokwu, cela nous indique que c'est un mot en langue igbo.
Ainsi, si on choisit le lexème mkpụrụokwu sur la page de la fonction langue du lexème, celle-ci nous renvoie l’objet langue et affiche le code langue ig (qui signifie igbo).
La fonction a un testeur, qui prend le lexème pour le nom anglais « dog » et renvoie l'objet représentant la langue anglaise.
Il existe une implémentation, une composition : elle utilise la fonction valeur par clé, une fonction fondamentale pour travailler avec des objets dans Wikifunctions. Chaque lexème est composé de sept clés, comme défini sur la page de type pour les lexèmes. Pour obtenir la valeur d'une clé spécifique, nous pouvons utiliser la fonction valeur par clé avec deux arguments : la clé que nous voulons rechercher, et l’objet lui-même sur lequel nous effectuons la recherche de clé.
Il est logique que la plupart des types aient une fonction pour chaque clé pour décomposer des objets du type. Le langage de Lexeme est une telle fonction : il choisit simplement une des clés de l'objet Lexeme et la renvoie.