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.

• 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?

Is the "0 items" always in English? Or is it translateable somewhere?

Thanks for your investigations.

In T394664#11252645, @GrounderUK wrote:

Is this still too “messy”?

I've raised a different ticket, T406848, for the wider Python issues in case they're different.

I nudged a similar one with issues, and now all tests fail: https://www.wikifunctions.org/view/en/Z19933

I've got problems with other Python implementations too. E.g. try to run https://www.wikifunctions.org/view/en/Z19943 with the input 0.1234

I'm not keen on this unless specifically requested as a flag by the function call to Fetch. IMHO the identifiers are actually the most important part of a Wikidata item. They make it a universal identifier hub. In fact I wrote an entire app, Entity Explosion, based on this (T253201). I'm not sure that aspect will be used very much on Wikifunctions, but it could. For example, we could create an HTML fragment like https://en.wikipedia.org/wiki/Template:Taxonbar for an arbitrary item type.

I found a current example, which I won't nudge: https://www.wikifunctions.org/view/en/Z25972

I don't understand "and other tests for Z7 results?".

Yes, we can reopen if we find any that weren't identified.

Yes, I've now changed that test so that it works. I'm happy for this task to be closed. https://www.wikifunctions.org/view/en/Z16573

In T366246#9845585, @GrounderUK wrote:

*https://www.wikifunctions.org/view/en/Z16573 is a test case linked directly to Z828. The failure is similar but the Z99K1 is not an empty object.

Yes, I cleaned up this particular instance with this edit: https://www.wikifunctions.org/w/index.php?title=Z19814&diff=194924&oldid=174222

In T404186#11191845, @99of9 wrote:

In T404186#11187954, @99of9 wrote:

I'm also seeing this at Z28323 complaining about connected implementations at Z28312.

This has now resolved. I wonder if it was somehow connected to the co-occurring T404797?

In T404186#11187954, @99of9 wrote:

I'm also seeing this at Z28323 complaining about connected implementations at Z28312.

I'm also seeing this at Z28323 complaining about connected implementations at Z28312.

I expect this shares a common cause with T403834

This seems like something the function writer and community should address.

https://www.wikifunctions.org/view/en/Z6895 seems pretty fundamental here and fails for chemical elements

In T402079#11131102, @GrounderUK wrote:

I think there’s some mechanism that allows a different implementation to be used if the preferred one fails, but it appears that didn’t happen here, perhaps because the failure was too orderly.

In T402079#11129136, @GrounderUK wrote:

Also observe issues with Z11410. For an unidentified reason, all implementations were observed to fail with a Z503 (including discard from start of first substring, JavaScript (Z14700)

It looks like the fix for T392473 has solved this one too. Closing.

I don't think this feature is necessary. It's simpler to line tests up with a single function.

Oh, hmm. @GrounderUK just nudged the composition and they're all working again. But something is wonky somewhere.

This is not technically a duplicate. Although it sounds like new deletions are getting checked and removed, there are still old ghost implementations causing problems.

Wonderful. Don't worry about the other tests, this was just a simplistic implementation to demonstrate the problem in JS.

This may be related to T394313

We have similar issues in Z25997 and Z25998

Another current example is at https://www.wikifunctions.org/view/en/Z14040

This seems closely related to T386553

Lilipad09 [https://www.wikifunctions.org/wiki/Talk:Z16137?uselang=en points out] that the order of months is currently better except that July and September are at the end of the list.

Similar issue for the lexeme type. Reported by @Ainali on Telegram at https://t.me/Wikifunctions/25993

The tests are now all passing when all implementations are connected. I don't know about the underlying issues, but on the surface this appears fixed.

Why invalid? I'm not invested in this, but it would be nice to know the reason we're not pursuing it, in case it is suggested again later.

Yeah, don't worry about readers and displays, there are a few of us who can do these.

In T386553#10946655, @gengh wrote:

@99of9 We can enable "Function call" there, I don't think that would be a problem, as long as we totally make sure literals are always excluded.

In T386553#10942979, @DSmit-WMF wrote:

Checking this.

I see we are excluding function calls from it:

Actually, that's not universal. For example, you can see it in operation here: https://www.wikifunctions.org/view/en/Z25328

The new display function achieves most of these goals and has been attached to the Type. Further improvements can be made by the community through regular edits.

Done. Thanks for figuring this out.

I think I've got all this working at https://www.wikifunctions.org/view/en/Z25326

This is what I get at https://www.wikifunctions.org/view/en/Z6821 when I call for Q6158. In this particular case, it can't even render the rationals because the import brought in a natural number of "1e+22" which is not a valid natural number format.

Hi David. Good news. We already have most of this in the pipeline. Some details:

• Unit symbols will be looked up per language (with fallback) from Wikidata (https://www.wikifunctions.org/view/en/Z23136)
• Decimals will be full length rather than truncated, unless they are coming from somewhere other than Wikidata so end up recurring and need truncation. (https://www.wikifunctions.org/view/en/Z25445)
• Decimals will be formatted according to language configuration so that separators and radix characters can be configured. (https://www.wikifunctions.org/view/en/Z25457 https://www.wikifunctions.org/view/en/Z25362)
• Quantities with symmetric bounds will get a plus/ minus symbol. (https://www.wikifunctions.org/view/en/Z25310 https://www.wikifunctions.org/view/en/Z25356)
• Quantities with asymmetric bounds will get some kind of range, but will also show the central estimate so they can be read back in without distortion. (https://www.wikifunctions.org/view/en/Z25356)
• The final product is currently planned at https://www.wikifunctions.org/view/en/Z25326

I don't think it's an error in the display function, nor related to Wikidata. This is a familiar issue when the displays are required to run quickly and simultaneously during page rendering.

Can we promote this to fix this quarter? I was just blocked by this again when trying to construct a display function for one of the new types.

All testers are working. I fixed the test that python was tripping on (which had an invalid rational in it). This looks done to me.

These now seem to be working again.

I also hit this issue when trying to make a composition for Z25065 which involved calling Z24144

It seems to work fine in the UI

In T395464#10870819, @cmassaro wrote:

But again, I think it's cleaner if we work toward a situation where these functions are themselves produced by another function, i.e. where we don't just have a function

function doSomethingWithAList( listInput: Z881(Z1) ) { ... }

but where we have a function that returns a type-specialized function, e.g.

function getDoSomethingWithAListFunction( elementType: X ) {
    return doSomethingWithAList( listInput: Z881(X) ) { ... }
}

Please don't change the Map function. You're right, we rely on it for some tricky typing stuff. If you want Typed alternatives, please build them elsewhere first so we can carefully monitor the switch to them.

Could that backstop inference work for situations like T394664 too? I understand that would mean mapping the type from input lists to output, but it might save a whole lot of issues.

In T394664#10867412, @cmassaro wrote:

In T394664#10867407, @99of9 wrote:

I guess it's still a disappointing outcome, because the code implementations were working before, and we've had to disable them and switch to the much slower recursive composition. Many of the fails are this new "unspecified error" which is now popping up everywhere, and so I was still hopeful that when something gets fixed, it could handle these too.

Yeah :-/. This is a casualty of how we're handling type conversion, which relies on precise type specification for outputs. I think that the situation with type conversion will improve over the next year, but I don't see any outcome where Z1 as an output type will continue to yield good results.

Would it be helpful if it were easier to parameterize functions like "get nth element of a list" by output type? I welcome you to open another Phabricator task so we can discuss options.

In T391435#10760218, @99of9 wrote:

It seems like this problem may be associated with particular Types within Typed lists.

see https://www.wikifunctions.org/view/en/Z24212 where the test on natural languages works but a similar test on natural numbers doesn't.