Wikifunctions:Status updates/2024-06-06

◀

Wikifunctions Status updates

▶

New Type: Sign

We are introducing a new Type this week: Sign.

Sign is an enumeration with three values:

We don’t expect a huge amount of functions to work only on Signs, but we introduced two functions for Signs as example functions: a function to check two arguments of Sign for equivalence, and a function that inverts a given Sign.

We introduced Sign this week in preparation for our first complex on-wiki defined type, Integer, i.e. Natural numbers with a Sign. But our tests surfaced a few issues which we would like to iron out before we introduce signed Integers. It shouldn’t take too long! Until then, we would like to ask you to continue to not use the new Integer type. It is also clearly marked as “Do not use”.

Recent Changes in the software

Last week was one of our regular "Fix-It" weeks, where we work on technical debt, product tweaks, design issues, and other smaller things.

In terms of user-facing improvements, there were four items you might notice. We fixed the error handling of Type display functions ("renderers") to work when in view mode, as well as in edit mode (T362519). We found a code error that meant that back-links (which power Special:WhatLinksHere) were mostly not being populated; this should now be fixed, and Objects' listings will slowly fix itself as the pages are re-parsed or edited (T361701). We fixed the placeholder for adding text to a Z11/Monolingual string that was hard-coded in English (T359782). The front-end code now more consistently drops empty labels and re-numbers keys when publishing, which should avoid occasional breakages (T359869).

We made a number of improvements to the front-end Vue code, including reducing the number of emitted events between components, re-using convenience methods, and extending and improving tests. We also landed a comprehensive re-organising and re-naming of our code base to be consistent and reflect our newer understanding of what is needed and where. We reduced the number of functions our older code was injecting into the global scope, though there's more to do here.

When we re-platformed our front-end interaction metrics to the Data Platform last month, we missed events related to content being changed; these are now measured consistently with the old data schema, on Function edits and "About dialog" edits as well as other kinds (T365548). We've also started tracking how often people make function calls at the PHP layer, not just the JavaScript UX one, so we can more directly measure the use of function calls (T356228 and T360369).

We (hopefully!) fixed a few production issues. First, API requests for Objects were sometimes but not repeatably failing when fetching dependencies with non-current revisions (T365152). Second, some code paths related to running Tests are apparently trying to set invalid languages; we now fail safely and log, for future improvements (T364961). We accidentally rolled out to the Beta Cluster a broken version of the function-orchestrator; to make debugging these issues easier in future, we've added better logging in the function-call API code.

Both last week and this week, we deployed our production services to newer versions.

The function-orchestrator has had some improvements related to our Quarterly work on easier debugging for Wikifunctions editors (T363384), attaching function call execution "scopes" more consistently (T337589), and re-working the pipeline so that we will be able to inject and merged sub-call meta-data when it becomes available (T351473). We also incrementally worked on the technical debt around removing the legacy support for inline Z61/Programming language objects rather than references (T287154). Our code to request copies of Objects from the wiki can now have its rate limit and time-to-live configured (T340561), and we now test this (T340562). We've generalised our code related to identity key finding and shared it between repos (T350176), and made our code to set and adjust meta-data values mutate a given object rather than clone it (T365151)

On the function-evaluator side, we added a more direct way to kill off the executor process once completed, contrary to how docker tries to manage our threads; this should avoid long-running, unattached zombie processes we found in production (T364889). As well as this, we now test better for several invalid outputs from the executors (T362703), pin the version of RustPython (T364563) and QuickJS (T364564) we ship in WASM to specific commits. We've cleaned up a messy integration layer with WASM-edge, now we have a better understanding of it (T362738). We've improved our benchmark testing to avoid rate limiting, which artificially altered their results and sometimes made them fail (T363710).

We tweaked our languages, updating Z1394/sr-latn and Z1181/sr-cyrl to have the international standard language codes as their primary, and MediaWiki's non-standard codes 'sr-el' and 'sr-ec' respectively as a secondary code (T360676 and T360677). We have added support for the Z1923/ekp "Ekpeye" language, as part of it being supported across MediaWiki (T365263).

We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.6.1, as of this week, which includes the roughly annual increase of our version of Vue from 3.3.9 to 3.4.27 (T364789). It should have no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue.

Volunteers' Corner on June 3rd

We met with some of our wonderful Wikifunctions volunteers on Monday. We discussed our recent updates and built a function together, as is customary in this meeting. The recording of the meeting is available on Wikimedia Commons.

Function of the Week: Is this month after that month?

Each month in the Volunteer’s Corner, we build a Function together. This week it was “is this month later than that month in the year?” (Z16648), inspired by the already existing complementing function “is this month before that month?”. The function takes two months and returns a Boolean: if the first month is strictly after the second one in the order of the months during a calendar year, it returns True, else it returns False.

We created four tests:

November is after February, testing a true case
June is not after December, testing a false case
December is after January, testing an edge case
January is not after itself, testing the strictness of the function

In theory, the tests could be complete, but that would lead to 144 tests, and I am not sure we want that. I am pretty sure that Wikifunctions would have trouble dealing with this many tests.

We had five implementations created, one in each of the programming languages we support, and three compositions. It may be instructive to look at the different compositions and try to understand them.

In JavaScript we just use the “>” operator, “larger than”, since for JavaScript we convert the months to numbers which represent their order in the list of months
Same thing in Python
One composition follows the same pattern as the previous two implementations: it first turns the two months to their respective month numbers, and then uses the greater than function to compare them.
One composition just uses the existing complementing function, “is this month before that month?”, but switches the arguments. Because asking whether June is before June answers False, which is also the case for asking whether June is after June – that is called strictness in this case – simply switching the arguments works also for the edge cases.
The final composition we have also uses the “is this month before that month?” Function, but then uses negation to turn that answer around. Since that would lead to a mistake in the case that both arguments are the same month, we precede this with an if-check to see if the two arguments are the same month: if they are, we return false, covering that edge case.

Thanks to everyone who joined the Volunteer’s Corner! You can check out the recording to see this Function being created.