@cmassaro I hope you don't mind if I tag you into this. I think something near this is causing us major problems today.

I wonder if it's another expression of the problem at the heart of T427644?

Thanks for explaining @cmassaro and thanks for fixing @Feeglgeef. Many of our dispatchers are smarter (e.g. apply3/4), but it's nice to have consistency and associated speed.

IMO this should be higher than medium. This causes problems that AFAIK we cannot work around because code implementations can't "apply" other functions. When the rubber hits the road this is causing actual bad output in AW:

I think this or something similar is affecting Z32885, possibly via Z14779

To me it's important in the long run, but not a super high priority until we are bot-templating articles that need to fetch Wikidata-curated images automatically. When we're building an article by hand it's not hard (and more fun) to look up an image of choice.

Sure, you can put it that way if you like. I expect the problem is true for everyone's browser though. Try loading the link above, you'll see how tortuous it is.

In T423180#11833513, @Jdforrester-WMF wrote:

In T423180#11833180, @Bugreporter wrote:

They are still valid reason to have external links in text, though they should pass through SpamBlacklist. They are usually discouraged in article body (i.e. other than navbox and external links section) though.

Please file a different task, rather than derailing this one.

Is the definition of a "reference" anything in a <sup>? Yes, links will often be desirable as links in plain/"main" text. See these sections of a featured article, especially the Authority control box:

This result shows that although the html output looks okay, the UI renderer is still too nervous to show the link?

I think I favour: It shows up in the ULS language list on e.g. [[ak:Douglas Adams]] as a normal "article" but with a special icon

We will get Julian dates eventually. IMO this is covered by "Wikifunctions is under development."

Sorry, my bad, I was comparing a list of references to a reference.

In T421468#11835425, @DMartin-WMF wrote:

Accordingly, what's needed is an equality function for Monolingual stringset that allows for both reference and literal representations of Z31K1/language. The best way forward is this:

1. Create a new equality function for comparing 2 instances of Z60.
   1. I propose to make this a built-in; It's easiest and most performant that way.

With pleasure.

I'm boldly closing this as resolved. The initial bug report is certainly addressed. The current system is working pretty well. If we want to suggest refinements, that can be a new feature request.

Thanks for the responsiveness. We'll surely let you know if it happens on other Types!

possibly related: https://www.wikifunctions.org/wiki/Talk:Z16684

Here's another clue: pi/4.0 gives
"Error in the function call API (propagated error: "Status 503 from wikilambda_fetch (ZIDs <Z21033>)")
Error type: Error in the function call API
Error data:
propagated error: "Status 503 from wikilambda_fetch (ZIDs <Z21033>)""

Hooray! Congrats, this was a big one.

I agree that semi-special is a good way forward. Another advantage over full auto is that it can be queried in SPARQL, so analysis will be easier.

Adding it to essential work sounds excellent. But if fixing v2 issues was part of the quarterly goal, isn't it okay to also leave this there as a (so far) unmet component of the goal?

Why is the v2 parent removed? I thought this worked in v1.
I'm using the v2 parent to keep track of dev progress on recent fixes after the v2 shake up.

I don't think I have much insight here. If the answer is we're not allowed this behaviour anymore, I don't think that's a big deal. None of the current usage looks compelling.

Oh, sorry. I'm not sure. I tried it with a different input and it failed:
https://www.wikifunctions.org/view/en/Z10249?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z10249%22%2C%22Z10249K1%22%3A%22abcd%22%7D

Confirmed. Thanks.

• I have no issues with the restriction to Commons as our only source.
• As a first pass it would even be okay if it excluded timed media, or even SVGs.
• The rest sound reasonable.

Yes, this particular test now works. (although as I understand it, we're now using v1 again anyway)

I think the failure of https://www.wikifunctions.org/view/en/Z28849 (every test case) may be related. In particular I think https://www.wikifunctions.org/view/en/Z28686 is receiving objects in unexpected form.

Okay, I withdraw the word "fixed", but that is not the important issue.

In T419789#11717526, @ChaoticVermillion wrote:

I think the culprit is Z20343 (month from day of the Roman year), which seems to return a calendar month, nested in a calendar month, nested in a calendar month. I presume the triple nesting causes errors downstream. Look at this link: https://www.wikifunctions.org/view/en/Z20343?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z20343%22%2C%22Z20343K1%22%3A%7B%22Z1K1%22%3A%22Z20342%22%2C%22Z20342K1%22%3A%7B%22Z1K1%22%3A%22Z16098%22%2C%22Z16098K1%22%3A%7B%22Z1K1%22%3A%22Z16098%22%2C%22Z16098K1%22%3A%22Z16101%22%7D%7D%2C%22Z20342K2%22%3A%7B%22Z1K1%22%3A%22Z13518%22%2C%22Z13518K1%22%3A%2215%22%7D%7D%7D

The double nested signs seem to originate in the js rational conversion from code. This could also be simplified? https://www.wikifunctions.org/view/en/Z19702

I don't think so. What do you see? (I've also tried other values to go without the cache)

Yes, I'm happy to call this one resolved, and have filed tasks for some similar but different issues.

Where do we read about the new composition language? Is there a task to follow (and connect to this one)?

In T383842#11572688, @Jdforrester-WMF wrote:

the user-land hack is unstable, unstable, and will likely break soon

This is concerning. Where can we learn more about this?

In T407932#11575188, @GrounderUK wrote:

I’m not sure how we could apply an absence of conversion to a returned value, other than by returning a map or using ZObject(), ZReference() or ZPair(). Given that we now have those options, we might consider converting numbers by default, according to their native type, I suppose, but if the function’s return type is explicit, it should be respected.

An example of where we need close-to-raw returned values is https://www.wikifunctions.org/view/en/Z26982 (equal rational with numerator length). The crucial requirement is that we separately return each of the keys of the object we are returning, and they don't get messed with during the conversion from code. Can we already do this with ZObject()?

• Does this only apply to inputs? To outputs? To only some inputs? Etc.

Some of the other answers may depend on the decision here, so I'll answer it first. I suppose the ultra-flexible ideal would be to selectively apply to whichever inputs and outputs the implementation creator chooses. My specific proposal is for all inputs and all outputs, because I expect that will be easier to design, because this will only be needed in rare circumstances, because it does allow code to access everything, and because those who use it will be willing to go the extra mile on raw-processing other inputs/outputs if they need it for one. I'm open to seeing different designs before weighing in on whether I expect they would work.

@GrounderUK has made them work by wrapping with https://www.wikifunctions.org/view/en/Z104, so the actual block to progress is resolved.

I don't mind changing it, but it appears to be passing all implementations at the moment?

I agree with your final recommendations.

Another early attempt that might be related is https://www.wikifunctions.org/wiki/Z10111. I haven't looked at why it's not working.

Thanks Daphne @DSmit-WMF , looks good. Every little simplification of the flow helps.

Thanks everyone. Looks great. Now we just have to make sure that any future heavyweight enum items are created in sensible order.

Yes, the behaviour is different now.

I agree with Al, but for the last 3 days it has been a continuous and widespread breakage, even when python tech was reset. So I think it's important to have this new Phab report to focus everyone's attention.

I also can't reproduce the original bug report. @VIGNERON?

In T397542#10936478, @99of9 wrote:

Try running this function on a string of about 30 characters. Many will fail, especially later on in the list. https://www.wikifunctions.org/view/en/Z22717

A similar message is still there if you collapse the expanded carrot:

Yes I think I saw this occasionally, but I'm not doing much at the moment. In fact, nobody is, so I'm having trouble understanding why the servers would be overloaded! Is there web-crawler activity again?

I sometimes use this "feature" to re-attempt renders which failed the first time. Perhaps you can try to keep track of this and selectively re-render?

Another example to check on closing is https://www.wikifunctions.org/view/en/Z28245 acting on https://www.wikifunctions.org/view/en/Z28244

Looks good at the user end.

I'm not sure if it's actually possible to do in the regular interface. I went into manual edit mode to copy what Denny/Al had done. But in any case, that level of difficulty is worth it for this kind of rare but enabling need.

Admittedly, soon after I loudly complained, Al Grounder showed me that we can already manually do something like your option 1 (at least) for any finite Apply. For example, I've now got apply3 working at Z29365. So the urgency of the list version is no longer as clear. But if it's easy to implement, it will surely prove useful too.

Who can we talk to about the prioritisation here?