The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-11-01 -- Rewriting the backend https://www.wikifunctions.org/wiki/File:Rust_programming_language_black_logo.svg
The Abstract Wikipedia team is working toward a rewrite of our backend services in a different programming language, likely Rust. Node/JS has served us well, but we have run up against some limits that would be best dealt with by switching to a different ecosystem. The immediate work surrounds how we might better interact with WebAssembly (WASM). Almost precisely one year ago, we announced https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-10-25 that we would begin running Python and JS code in WASM for its sandboxing characteristics. Since then, we have been interacting with WASM via the WebAssembly System Interface (WASI), which allows WASM commands selective access to the underlying operating system.
While WASI has made our code executors more secure, the use of this tool has caused some bumps. The Node tooling around WASI is not particularly rich. At the time of adoption, we found that our best option was to use WASI command-line interfaces. We decided to run these interfaces in subprocesses. The use of subprocesses has resulted in system stability issues, mainly related to the impossibility of cleaning up subprocesses under certain conditions.
The WASI ecosystem in Rust is much more advanced. Several WASI runtimes provide tools which offer fine levels of control over the binding of WASM commands to syscalls. With these tools, we can streamline our use of WASI. We can run our code executors directly inside of the host Rust program, eliminate subprocesses, and thereby avoid several sources of system instability. As an added bonus, this level of control means that we can also improve our sandboxing–a security win–and, in the far (or not so far?) future, co-opt certain system calls to implement new features for our code executors. Upcoming Volunteer’s Corner on November 4
Next week, on Monday, 4 November 2024, at 18:30 UTC https://zonestamp.toolforge.org/1730745000, we will have our monthly Volunteers’ Corner. Unless you have many questions, we will follow our usual agenda, of giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together. Looking forward to seeing you on Monday! Function of the Week: language of lexeme
Function Z19295 is https://www.wikifunctions.org/view/en/Z19295 a simple function: it takes a single argument, a lexeme https://www.wikifunctions.org/view/en/Z6005, and returns the (natural) language https://www.wikifunctions.org/view/en/Z60 of the lexeme. Each Lexeme in Wikidata belongs to exactly one language, e.g. if we take a look at the lexeme L610505 https://www.wikidata.org/wiki/L610505, *“mkpụrụokwu”*, it tells us that it is a word in the Igbo language https://en.wikipedia.org/wiki/Igbo_language.
Accordingly, if we choose the Lexeme *“mkpụrụokwu”* on the function page for language of lexeme https://www.wikifunctions.org/view/en/Z19295, it returns us the language object, displaying the language code ig (which stands for Igbo).
The function has one tester https://www.wikifunctions.org/view/en/Z19297, which takes the Lexeme for the English noun dog https://www.wikidata.org/wiki/Q1122 and returns the object representing the English language https://www.wikifunctions.org/view/en/Z1002.
There is one implementation https://www.wikifunctions.org/view/en/Z19296, a composition: it uses the value by key function https://www.wikifunctions.org/view/en/Z803, a foundational function to work with objects in Wikifunctions. Every lexeme https://www.wikifunctions.org/view/en/Z6005 consists of seven keys, as defined on the type page for lexemes https://www.wikifunctions.org/view/en/Z6005. In order to get the value of a specific key, we can use the value by key function https://www.wikifunctions.org/view/en/Z803 with two arguments: the key https://www.wikifunctions.org/view/en/Z39 we want to look up, and the object itself on which we perform the key lookup.
It makes sense for most types to have a function for each key to decompose objects of that type. Language of Lexeme is such a function: it simply picks one of the keys of the Lexeme object and returns that.