[05:04:01] I'm not sure whether Z23168 is a new bug or not. It looks like it's due to different representations of the languages in the monolingual texts. This could be due to what comes back from the Wikidata statements David . Or it could be a new V2 issue @apine. Or it could be over-strictness in Z12846 Al . [10:09:41] I don’t know about over-strict… I don’t think the elements match, in Python terms or otherwise, because the Z11K1s in the expected results contain ZReferences whereas the Wikidata ones contain Z60 objects. This seems to be a v2 change. Note that Z12879 has passing tests from “6 months ago” and now fails with [10:09:41] Error type: Unspecified error (https://www.wikifunctions.org/view/en/Z500) [10:09:43] Error data: [10:09:44] error information: "cannot read property 'Z1K1' of undefined" [10:09:46] I’ve added Z32039 to get the function working again, which will purge the old test results for the JavaScript implementation when I connect it (I expect). (re @u99of9: I'm not sure whether Z23168 is a new bug or not. It looks like it's due to different representations of the languages in the mon...) [16:27:13] I just want to express thanks for all of the bugs being filed so quickly!!! We're working on it. As mentioned, if this change has proven completely disastrous, we are able to roll back and iterate a bit offline. Every bug I've tried has been easy to replicate locally, so the fixes can happen async. That said, I hope to get a few fixes out today and see where we are. [17:22:55] Luckily, we don’t have to report all the improvements! I think it’s shaping up really nicely. (re @wmtelegram_bot: I just want to express thanks for all of the bugs being filed so quickly!!! We're working on it. As mentioned, if this c...) [17:25:16] Ooh, are there some visible functional improvements? Of course no need to report them, but the ego boost will get us through 😤 [18:08:20] Yes. It’s not single-digit ms (lots of those observed) but this new implementation is both snappy and (I trust) delightfully robust: Z32016. (re @wmtelegram_bot: Ooh, are there some visible functional improvements? Of course no need to report them, but the ego boost will get us thr...) [20:58:18] I just found a nice example. [20:58:19] Before: [20:58:20] *Implementation [20:58:22] *same Key reference, composition [20:58:23] *Duration [20:58:25] *67 ms [20:58:26] Orchestration: [20:58:28] Duration: 67 ms [20:58:29] Start time: 6 months ago [20:58:31] End time: 6 months ago [20:58:32] *CPU usage [20:58:34] *21.35 ms [20:58:35] After: [20:58:37] *Duration [20:58:38] *12 ms [20:58:40] Orchestration: [20:58:41] Duration: 12 ms [20:58:43] Start time: 2 seconds ago [20:58:44] End time: 2 seconds ago [20:58:46] *CPU usage [20:58:47] *9.889 ms (re @wmtelegram_bot: Ooh, are there some visible functional improvements? Of course no need to report them, but the ego boost will get us thr...) [20:59:16] <3 <3 <3 [20:59:31] This is excellent; I'm glad to see that these improvements show up in prod. [21:22:10] Z32049, new composition for [is String] using only pre-defined functions, is now preferred over the JavaScript version, mostly completing in half the time/CPU. (re @wmtelegram_bot: This is excellent; I'm glad to see that these improvements show up in prod.) [21:23:53] Hahahaha, it's sad that the bar we had to beat was, "Do better than a 20ms round trip to a separate service," but so it goes. [21:46:23] Well… the benefits compound. Z18998 often had performance in the hundreds of ms. Now it’s down to around 50 and I’m hopeful we’ll get down below 15 if you can fix Z803 for strings (and, currently, Booleans) 🤞 (re @wmtelegram_bot: Hahahaha, it's sad that the bar we had to beat was, "Do better than a 20ms round trip to a separate service," but so it ...)