[01:52:18] Can someone check the closure of *T360580*. To me it looks like it still has problems. I've added a comment at the end. [04:36:10] Yes… I was still getting the problem yesterday 🙄 (re @u99of9: Can someone please check the closure of T360580. To me it looks like it still has problems. I've added a comment at the end.) [09:01:08] It’s still happening so I’ve re-opened it and moved it back to incoming. (I’m not sure if that’s right, but if the rules have been published, I don’t know where.) (re @u99of9: Can someone please check the closure of T360580. To me it looks like it still has problems. I've added a comment at the end.) [09:06:36] Raised *T391435* [09:06:37] as a Generic Task. It should probably be Bug Report or a Production Error (or even a Spike Task) 🤷‍♂️ (re @Al: There seems to be something wrong with typed list’s going into Python. Z17616, for example, completes in under 1s with JavaScrip...) [11:56:15] I didn't expect to hit a recursion limit here Z23468 (the composition for the dog test, although it shows differently from within the test) : https://tools-static.wmflabs.org/bridgebot/9d153800/file_69842.jpg [12:02:36] I suppose it drops down a level for each label in the Wikidata item, and there are rather a lot of those… 🤷‍♂️ (re @u99of9: I didn't expect to hit a recursion limit here Z23468 (the composition for the dog test, although it shows differently from withi...) [12:09:55] Ohh... inside Z16277? But I think it should now be using Z23758 instead of Z16279. But maybe it's a caching issue. I'll try to check back on this later. (re @Al: I suppose it drops down a level for each label in the Wikidata item, and there are rather a lot of those… 🤷‍♂️) [12:20:07] Just in the orchestrator, I think. (re @u99of9: Ohh... inside Z16277? But I think it should now be using Z23758 instead of Z16279. But maybe it's a caching issue. I'll try to c...) [12:21:39] I don't really understand what an orchestrator does. Does this mean that it will recurse through non-preferred implementations before it even starts evaluating? (re @Al: Just in the orchestrator, I think.) [12:41:39] The orchestrator _orchestrates_ the _resolution_ of _Z7s_, the evaluator _evaluates_ Z16s (re @u99of9: I don't really understand what an orchestrator does. Does this mean that it will recurse through non-preferred implementations b...) [12:42:52] When you run a function call nearly all the work is done in the orchestrator, besides the evaluation of python or js [12:44:16] So it's the one that should figure out not to use the non-preferred implementation? [12:44:46] I think (re @u99of9: So it's the one that should figure out not to use the non-preferred implementation?) [13:07:24] The “preferred” implementation should be demoted by WikiLambda system, but the competing implementations also fail (possibly for the same reason, if you did but know it). The last I heard, the preferred implementation was selected before the call to the orchestrator “in the PHP”. (re @u99of9: So it's the one that should figure out not to use the non-preferred [13:07:24] implementation?) [13:21:12] The preferred implementation is selected in the PHP, the orchestrator figures out to use it (re @Al: The “preferred” implementation should be demoted by WikiLambda system, but the competing implementations also fail (possibly for...) [13:21:31] I.e. it selects the first one unless there is a native exception [13:28:59] Generally not (perhaps never). The call to the evaluator requires a list to be converted to a nested structure. If a list is too long, the nesting will be too deep and orchestration will fail. Whether it tries again for a second implementation, I cannot say, but it will fail for the same reason if it does (unless it fails even earlier for some other reason). In short, [13:28:59] there’s a [13:29:00] limit on the length of a list. (I think.) (re @u99of9: I don't really understand what an orchestrator does. Does this mean that it will recurse through non-preferred implementations b...) [13:36:52] Then after all this I still don't understand why it would hit a recursion limit. The only recursive implementation here would never be called, because Z23758 is the preferred function, and is already at the top of the list of implementations. (re @Al: Generally not (perhaps never). The call to the evaluator requires a list to be converted to a nested structure. If a [13:36:52] list is too...) [13:37:53] The recursion is in the representation of a list as a nested structure. (re @u99of9: Then after all this I still don't understand why it would hit a recursion limit. The only recursive implementation here would ne...) [13:40:08] So it's nothing to do with the implementations? Would this happen if I just echoed a list of 100 numbers? [13:43:48] Some number of numbers, yes. (re @u99of9: So it's nothing to do with the implementations? Would this happen if I just echoed a list of 100 numbers?) [13:46:41] Wow, well that's an issue I didn't expect to ever be a problem! In simulations I routinely set up lists of tens of thousands of items (particle positions or similar). Is there a fundamental design issue here? [13:51:57] I think so. JSON supports arrays but our current object representation does not use them. There would still be some practical limit even if we did, because JSON is relatively verbose. (re @u99of9: Wow, well that's an issue I didn't expect to ever be a problem! In simulations I routinely set up lists of tens of thousands of...) [14:12:45] James merged a patch right now about this, about the new ticket I saw I think it will be taken next week (re @Al: T391022) [20:46:53] This is because doing so is anti-normal-form. (re @Al: I think so. JSON supports arrays but our current object representation does not use them. There would still be some practical li...)