[00:42:38] I can't publish a composition! : https://tools-static.wmflabs.org/bridgebot/813b1248/file_70792.jpg [00:43:53] second part. When I press "Publish" it just clicks in and clicks out then does nothing else. : https://tools-static.wmflabs.org/bridgebot/7d2db9a2/file_70793.jpg [00:44:43] If anyone wants to reproduce, here's the place to add it: Z13397 (re @u99of9: I can't publish a composition!) [00:47:57] Oh, nevermind, it worked when I tried recreating from scratch. Z24840. Strange glitch. (re @u99of9: I can't publish a composition!) [04:10:47] David another one likely for you. Z22971 fails (orchestration recursion limit) in the composition, even though it is only a single element list, and the composition works for other types. [06:56:04] Al I just disconnected Z19104 which was the preferred implementation, because it currently fails equality of the complex types (e.g. Z24842 and Z24843). Because this is such an important function, this could have wide ranging effects on composition behaviour. For example, I started fiddling because Z18128 was failing almost all tests (unfortunately it still is). I [06:56:04] think there's [06:56:05] something seriously wrong, somehow related to "Unspecified error" noted in T394769. [07:10:25] Similarly I just disconnected Z12711 and Z12863 which were two of the fastest implementations, because they are failing some really simple tests (e.g. Z24323). The python debug on that one is reminiscent of the confusion between references and values, but I don't have time right now to go into it deeply. (re @u99of9: Al I just disconnected Z19104 which was the [07:10:25] preferred implement [07:10:26] ation, because it currently fails equality of the complex types (...) [08:37:37] I think Z18128 needs an accumulator, which probably implies a helper function? [08:37:38] I’m a bit overloaded at the moment, I’m afraid, but it looks like the problems are with the implementations themselves, because object equality is hard! (re @u99of9: Al I just disconnected Z19104 which was the preferred implementation, because it currently fails equality of the complex types (...) [08:57:12] In that specific case, I think it’s just the absence of type conversion for elements in an untyped list 🤷‍♂️ (re @u99of9: Similarly I just disconnected Z12711 and Z12863 which were two of the fastest implementations, because they are failing some rea...) [08:57:38] Fair enough. I'm not sure what you mean about an accumulator. It already wraps the recursive call in Z13578. (re @Al: I think Z18128 needs an accumulator, which probably implies a helper function? [08:57:39] I’m a bit overloaded at the moment, I’m afraid, ...) [09:05:55] Thanks I'll look into that. (re @Al: In that specific case, I think it’s just the absence of type conversion for elements in an untyped list 🤷‍♂️) [09:09:22] Yes, but the recursive call can still only return 0 or 1. You would need to pass the incremented value to the (new) inner function for it to be incremented at each recursion (which is what I meant by “accumulator”. Alternatively, you could compare the lengths of the original and final lists, but that’s a whole other implementation. (re @u99of9: Fair enough. I'm not sure [09:09:22] wha [09:09:23] t you mean about an accumulator. It already wraps the recursive call in Z13578.) [09:13:08] Can't it return incr(incr(incr(1))) etc? (re @Al: Yes, but the recursive call can still only return 0 or 1. You would need to pass the incremented value to the (new) inner functi...) [09:19:15] Conceptually, a function could. But that’s not what this function can do; it can only return a Natural number. (re @u99of9: Can't it return incr(incr(incr(1))) etc?) [09:20:35] Let's say the true match is the element 3 of [1,2,3]. The outer call returns incr(index in [2,3]). Index in [2,3] returns incr(index in [3]). Index in [3] returns 1. So the outer function returns incr(incr(1))=3 (re @u99of9: Can't it return incr(incr(incr(1))) etc?) [09:21:25] Yes incr(1) is 2, a natural number. (re @Al: Conceptually, a function could. But that’s not what this function can do; it can only return a Natural number.) [09:26:26] But in the case when you finally call this function with the matching element in first position, it will return 1. (re @u99of9: Yes incr(1) is 2, a natural number.) [09:27:11] That's the most inner of all the recursions, it still has to propagate back out to give the final answer to the initial outer call. [09:28:58] It would need to. But it returns 1 unconditionally. (re @u99of9: That's the most inner of all the recursions, it still has to propagate back out to give the final answer to the initial outer ca...) [09:32:07] Each layer it propagates back out it should get an additional increment, because that's how the recursive calls were wrapped. (re @Al: It would need to. But it returns 1 unconditionally.) [09:33:06] I understand… But you do always get a 1 back 🤷‍♂️ (re @u99of9: That's the most inner of all the recursions, it still has to propagate back out to give the final answer to the initial outer ca...) [09:35:38] Currently, yes, which is why I think there's a system bug. I think this composition worked when I wrote it in July 2024. I'll have a look at some similar recursive compositions. (re @Al: I understand… But you do always get a 1 back 🤷‍♂️) [09:45:03] Z23887 is more complex, but similar, and works... [09:49:09] Yes. I told you I was overloaded… It might be that the first recursion always returns 0, which is then incremented to 1, but there’s no obvious reason why that might happen. (re @u99of9: Currently, yes, which is why I think there's a system bug. I think this composition worked when I wrote it in July 2024. I'll ha...) [09:49:12] Aha. I got it to return a 2. My new hypothesis is that it is using cached results for all the testers object equality tests, and thinks they are all successful, so always returns 1. : https://tools-static.wmflabs.org/bridgebot/d80ee1b0/file_70812.jpg [09:51:21] Yes, go clear your load. I'll look into the avenues you've suggested. (re @Al: Yes. I told you I was overloaded… It might be that the first recursion always returns 0, which is then incremented to 1, but the...) [09:56:00] They all pass in Edit apart from Z18503, which times out. (re @u99of9: Yes, go clear your load. I'll look into the avenues you've suggested.) [09:57:19] Yes, I disabled the other two implementations, and nudged the cache... so it's now behaving as expected!!! (re @Al: I understand… But you do always get a 1 back 🤷‍♂️) [09:58:45] But all of that means I still have no idea what caused the bad cache in the first place. (re @u99of9: Yes, I disabled the other two implementations, and nudged the cache... so it's now behaving as expected!!!) [10:07:00] Probably implementation switching. I think we’ve been here before. For the outermost evaluation, the targeted implementation is used, but the recursion just uses the “best”? (re @u99of9: But all of that means I still have no idea what caused the bad cache in the first place.) [10:07:01] OHHH... or maybe it's not the cache. When I re-enabled the other implementations, the recursive one failed again. (re @u99of9: But all of that means I still have no idea what caused the bad cache in the first place.) [10:08:51] Agreed, the first inner call should use "best". But the incr should still be applied to the number it receives. (re @Al: Probably implementation switching. I think we’ve been here before. For the outermost evaluation, the targeted implementation is ...) [10:11:24] But if “best” fails in the “contains” condition, it will return 0 from the first recursion and that 0 gets incremented to 1 for the returned result 🤷‍♂️ (re @u99of9: Agreed, the first inner call should use "best". But the incr should still be applied to the number it receives.) [10:21:07] …not in the “contains” condition… but if “best” returns 0 (incorrectly) 🤯 (re @Al: But if “best” fails in the “contains” condition, it will return 0 from the first recursion and that 0 gets incremented to 1 for ...) [10:35:40] but now I'm confused because best=JS is working... and yet the composition went south again when JS was re-enabled. (re @Al: …not in the “contains” condition… but if “best” returns 0 (incorrectly) 🤯) [10:45:19] That suggests that it is using best=JS in the recursion, though 🤷‍♂️ (re @u99of9: but now I'm confused because best=JS is working... and yet the composition went south again when JS was re-enabled.) [10:46:26] Agreed, I think it is and should be, but that should not return 0 (because it's working)... [10:56:05] T395431 [11:49:22] Yes, you were right on this. I've re-enabled those implementations and changed the test. (re @Al: In that specific case, I think it’s just the absence of type conversion for elements in an untyped list 🤷‍♂️)