[03:11:02] T390130 (re @u99of9: Do you also see these blank month-dropdowns when you go to edit at https://www.wikifunctions.org/wiki/Z16710?uselang=en&action=e...) [03:51:36] I think a filter function that accepted two-parameter functions would be useful. For example, Z13081 could just filter by Z23578(list_element, remove_element). I know I've wanted this before, but I've forgotten the other context. [06:02:45] This got deployed today. By retrieving an item from Z6821 or lexeme from Z6825, one can see that the monolingual text objects now contain literal instances of Z60, and the Wikidata statements contain literal instances of Z6040, for the rank. Hope that now enables fixing the blocked functions; let me know if any further attention is needed. (re @David: I'm planning to [06:02:45] work on T3 [06:02:45] 88117, T388448, and T386426 in the coming days (2 of which are mentioned above). As noted in the tic...) [10:24:55] Nice. Thanks. Lots of issues have resolved. I'm still having trouble with Z23165, even though I think I've nudged it enough to forget the cache. (re @David: This got deployed today. By retrieving an item from Z6821 or lexeme from Z6825, one can see that the monolingual text objects n...) [10:46:46] It looks like it’s not matching on P5601 in the Bulgarian case. I think the other cases time out in the orchestrator before getting to Python, but I’m out of time now. (re @u99of9: Nice. Thanks. Lots of issues have resolved. I'm still having trouble with Z23165, even though I think I've nudged it enough to f...) [10:49:26] whoop, you may have got it. It is meant to be P5061. I guess the orchestrator shouldn't time out though. (re @Al: It looks like it’s not matching on P5601 in the Bulgarian case. I think the other cases time out in the orchestrator before gett...) [10:50:03] whoop, you may have got it. It is meant to be P5061. I guess the orchestrator shouldn't time out though. (re @Al: It looks like it’s not matching on P5601 in the Bulgarian case. I think the other cases time out in the orchestrator before gett...) [10:53:27] Yes, Bulgarian now works. But the other two get through the orchestrator in about 3000 ms for the JS implementation Z23166 , so why should they be so slow in python? (re @u99of9: whoop, you may have got it. It is meant to be P5061. I guess the orchestrator shouldn't time out though.) [10:54:02] Yeah… I fixed the other problem too… feel free to revert 😉 (re @u99of9: whoop, you may have got it. It is meant to be P5061. I guess the orchestrator shouldn't time out though.) [10:58:49] Yours looks better. But I still don't understand the timeout. (re @Al: Yeah… I fixed the other problem too… feel free to revert 😉) [11:02:36] Can’t help you there, I’m afraid 🤷‍♂️ (re @u99of9: Yours looks better. But I still don't understand the timeout.) [13:39:49] I’m also getting a timeout with a simple Z803 ("Z6001K5") on those objects, so what’s the JavaScript magic? (re @u99of9: Yours looks better. But I still don't understand the timeout.) [14:04:19] Trying metre in Z23051 causes a terminal error (browser reset), but hertz succeeds in 3234 ms (1240 ms CPU). In an aborted new test (Z23581, changed to hertz), the JavaScript error is Z572. (re @u99of9: Yours looks better. But I still don't understand the timeout.) [16:55:46] We've considered making these functions accept a list (instead of a single parameter) which would then be split out into an arbitrary number of keys on the internal function calls. This would be a way to get something like variadic args. If this is something that many people would find useful, please do make a Phabricator task! ( I think a filter function that accepted two-parameter functions would be useful. For [16:55:46] example, Z13081 could just filter by Z23578(list_element, remove_element). I know I've wanted this before, but I've forgotten the other context.) [17:26:46] In addition to *T357858 *and *T383842*? I was thinking of suggesting that the function argument should be a function call, but then my brain stopped working… (re @wmtelegram_bot: We've considered making these functions accept a list (instead of a single parameter) which would then be split out into...) [18:07:03] Ah! I forgot we had those. I think your request is bigger than those. I'll make a task to encompass those two and your request concerning `filter`. [20:33:12] Aren't all our higher-order problems solved with currying? (re @wmtelegram_bot: We've considered making these functions accept a list (instead of a single parameter) which would then be split out into...) [20:37:42] *T386422* (re @Feeglgeef: Aren't all our higher-order problems solved with currying?) [20:59:47] One more for Map function too while you're at it, thanks! (re @wmtelegram_bot: Ah! I forgot we had those. I think your request is bigger than those. I'll make a task to encompass those two and your ...) [21:01:01] *T390226* (re @u99of9: One more for Map function too while you're at it, thanks!) [22:52:09] Our previous attempts got "low priority", "no current plans" and "I forgot". So hopefully your new attempt gets more traction! 😁 (re @wmtelegram_bot: Ah! I forgot we had those. I think your request is bigger than those. I'll make a task to encompass those two and your ...) [22:58:07] I was just thinking about tagging implementations with a “filter” alias when all they do is filter… and perhaps “filter condition” when their motivation is to support filter by encapsulating the unpassable arguments? (re @u99of9: Our previous attempts got "low priority", "no current plans" and "I forgot". So hopefully your new attempt gets more traction! 😁) [23:06:38] Yeah. The prioritizing of community priorities isn't horrible but it's not as good as it should be. (re @u99of9: Our previous attempts got "low priority", "no current plans" and "I forgot". So hopefully your new attempt gets more traction! 😁) [23:19:04] We could have a list… 😏 (re @Feeglgeef: Yeah. The prioritizing of community priorities isn't horrible but it's not as good as it should be.) [23:23:29] I think catching errors would be at the top of mine… at least allowing a particular error type to be the expected result and the test to pass in that case. (re @Al: We could have a list… 😏) [23:23:41] Yeah (re @Al: I think catching errors would be at the top of mine… at least allowing a particular error type to be the expected result and the...) [23:24:12] And then higher-order stuff [23:26:12] Perhaps we could have a signable petition list on wiki? [23:26:49] We can if we like 👍 (re @Feeglgeef: Perhaps we could have a signable petition list on wiki?) [23:37:52] [[WF:FP]] (re @Al: We can if we like 👍)