[04:03:22] When we visit a function page, why does the interface start running every single test in every single implementation? Surely it should have cached values for most of them? I tried to find a fairly random example of a very simple fast function with a few tests and a few implementations. So I picked Z11349, and it's still showing this about 3 minutes later. : [04:03:22] https://tools-static.wmflabs.org/bridgebot/c7aa36ef/file_62581.jpg [04:07:59] After a few more minutes I got bored and refreshed the page, then they were all ticked, but every single one of them said they had run 9 minutes ago. : https://tools-static.wmflabs.org/bridgebot/147dfe04/file_62582.jpg [08:35:14] Now they are almost instantly ticked for me from “4 hours ago”, so that is as expected 🤷‍♂️ (re @Toby: After a few more minutes I got bored and refreshed the page, then they were all ticked, but every single one of them said they h...) [11:18:10] I've tested this hypothesis, and it works at Z17770. IMO this strengthens our need for [[Wikifunctions:Type proposals/configuration of functions for given types]] (re @Toby: Or maybe we need to break up functions like Z12668 into one for each type, e.g. "reverse list of natural numbers". Would that wo...) [11:58:20] Although I support that type proposal, I don’t think we want, as a general rule, to have a separate function for each type of list (when their implementations are effectively duplicates). (re @Toby: I've tested this hypothesis, and it works at Z17770. IMO this strengthens our need for [[Wikifunctions:Type proposals/configura...) [12:07:00] As you were writing that, I was restructuring this to segregate the functions that would need duplicate functions [[Wikifunctions:Catalogue#Functions_with_list_outputs]]. At the moment we already need duplicates for functions like n^2, so I guess that would need to be solved before lists. (re @Al: Although I support that type proposal, I don’t think we want, as a [12:07:00] general rule, [12:07:01] to have a separate function for each type of li...) [12:22:00] Well, I don’t know about “before”… There’s no apparent dependency. (re @Toby: As you were writing that, I was restructuring this to segregate the functions that would need duplicate functions [[Wikifunction...) [12:44:14] Do you have an example function? (re @Csisc1994: I think that we should also upload all medical functions to Wikifunctions.) [14:22:01] https://www.uptodate.com/contents/table-of-contents/calculators can be useful. (re @dpriskorn: Do you have an example function?) [14:22:32] Most of the applications are paid and monolingual. [16:44:12] [[wikifunctions:Wikifunctions:WikiProject Medicine]] [16:45:02] [[Wikifunctions:WikiProject Medicine]] [18:35:35] The tests on Z17791 should pass, but they dont. Is there a way to trigger a rerun? [18:44:04] They should re-run when reconnected but there seems to be a more general problem right now 🤔 (re @dpriskorn: The tests on Z17791 should pass, but they dont. Is there a way to trigger a rerun?) [18:55:50] Ah, it’s okay; the tests were calling the wrong function. I fixed one of them. (re @dpriskorn: The tests on Z17791 should pass, but they dont. Is there a way to trigger a rerun?) [19:36:39] My trick to trigger a rerun is to add a missing label or description (re @dpriskorn: The tests on Z17791 should pass, but they dont. Is there a way to trigger a rerun?) [19:43:42] My guess is that the generic last function doesn't work here as it returns a Z1. (re @Toby: Anyone want to help diagnose the "bigint are forbidden in JSON.stringify" error in the second test of Z17692?) [19:44:06] That would be very cool! (re @Csisc1994: I think that we should create a Python Package that loads and uses Wikifunctions implementations.) [21:28:30] I can make a try. (re @vrandecic: That would be very cool!) [21:28:46] This will be interesting for the Wikimania Hackathon. [21:28:57] Yes, *Z12965* fails the natural number test because it relies on Z12668 . I've disconnected it, so hopefully everything downstream will resolve. (re @vrandecic: My guess is that the generic last function doesn't work here as it returns a Z1.) [22:04:42] The same thing was also needed at Z16360 (re @Toby: Yes, Z12965 fails the natural number test because it relies on Z12668 . I've disconnected it, so hopefully everything downstream...)