[00:02:32] But successfully turns to Python when required. : https://tools-static.wmflabs.org/bridgebot/5a1f455d/file_74907.jpg [01:05:13] Time for the next code converter issue? I believe Z24537 fails in JavaScript because the JS implementation never gets the input keys properly (if you try just immediately returning a value, it still fails). So I presume that Z19701 has a problem with very large numerators and denominators, but I haven't noticed anything wrong in particular. Anyone else want to take a [01:05:13] look? [09:20:01] JavaScript won’t echo a Natural number with that number of digits either 🤷‍♂️ (re @u99of9: Time for the next code converter issue? I believe Z24537 fails in JavaScript because the JS implementation never gets the input...) [09:31:57] Oh… seems it will, after all… (re @Al: JavaScript won’t echo a Natural number with that number of digits either 🤷‍♂️) [09:55:58] Hmm… JavaScript seems to be able to handle either the numerator or the denominator, but not both (in Z20121). I was wrong about Natural numbers (or Z10015 was, which is itself “interesting”) [10:07:32] Our guts agree. (re @vrandecic: Abstract content will be CC BY SA, indeed. I guess we would need to ask a lawyer what that means for the text created, but my gu...) [10:08:36] Ah, not so “interesting”, just serialisation, of course 🙄 (re @Al: Hmm… JavaScript seems to be able to handle either the numerator or the denominator, but not both (in Z20121). I was wrong about ...) [10:32:33] The gcd function is recursive, so that might blow the call stack, I suppose 🤔 The iterative form in Z14707 succeeds in finding no common divisor greater than 1, but fails with a recursive version (where all tests pass). I suggest we adopt the iterative approach in Z19701. @vrandecic (re @Al: Hmm… JavaScript seems to be able to handle either the numerator or the [10:32:33] denominator, [10:32:33] but not both (in Z20121). I was wrong about ...) [11:26:52] I've been cheeky and did it iniline: https://www.wikifunctions.org/wiki/Z19701?uselang=en&diff=prev&oldid=225784 [11:31:09] but Z24537 still fails on against Z20855 [11:46:57] Looks like a failure in orchestration, probably a timeout or rate limit. It took only about 4 seconds in Z14707 but more than 9 for the test case 🤷‍♂️ (re @vrandecic: but Z24537 still fails on against Z20855) [11:47:57] would you mind filing a bug? I think that's a great localizable issue [11:48:55] Will do … later. (re @vrandecic: would you mind filing a bug? I think that's a great localizable issue) [11:50:22] thanks! [11:53:22] Z29082 (re @Al: The gcd function is recursive, so that might blow the call stack, I suppose 🤔 The iterative form in Z14707 succeeds in finding n...) [11:55:04] That's a big number for evaluation: : https://tools-static.wmflabs.org/bridgebot/f6d73e22/file_74924.jpg [13:57:45] Yes, I noticed. It seem QuickJS is not particularly quick with doing math with BigInts [13:57:59] but I think no bug needs to be filed anymore (re @Al: Will do … later.) [13:58:12] the issue was the Debug call in the converter inside the loop [13:58:13] https://www.wikifunctions.org/wiki/Z20855?uselang=en&diff=prev&oldid=225793 [13:58:58] once this was commented out, Z24537 now passes the JavaScript implementation! [13:59:37] Wikifunctions.Debug is quite slow, and if called many times in a loop, it will easily cause timeouts [14:00:50] Ah, thanks… I was just about to start it! I hadn’t noticed the debug, but… yeah… don’t do that 😎 (re @vrandecic: once this was commented out, Z24537 now passes the JavaScript implementation!) [14:02:09] my fault not catching it before connecting [14:05:19] I guess we’ll need the same change in Z19702 (re @vrandecic: my fault not catching it before connecting) [14:25:36] done https://www.wikifunctions.org/wiki/Z19702?uselang=en&diff=prev&oldid=225796 [14:25:51] i hope I didn't break things worse [14:28:09] I think I did [14:31:50] It’s okay with existing tests on Z20112. I’m just setting up a more challenging test. (re @vrandecic: I think I did) [14:32:37] i just reverted it, it failed a simple run of Z24429 [14:34:38] Okay. I’ll set up the test anyway… (re @vrandecic: i just reverted it, it failed a simple run of Z24429) [14:38:44] yes, please, I think I figured out my mistake [14:41:57] ok, the change is in again, and this time it seems to work. Looking forward to your test to stress test it [14:51:24] Not too much stress… but JavaScript seems to beat Python: Z29083 (re @vrandecic: ok, the change is in again, and this time it seems to work. Looking forward to your test to stress test it) [14:53:17] Actually, that’s odd (as it were) because they can’t be co-prime… (re @Al: Not too much stress… but JavaScript seems to beat Python: Z29083) [14:55:14] Now, QuickJS beating Python is odd, given the behavior on Z24537 [14:57:59] I chose much smaller ints. The UI doesn’t lend itself to handling very long numbers. (re @vrandecic: Now, QuickJS beating Python is odd, given the behavior on Z24537) [15:31:46] No, I see they are much smaller, but I am surprised that "very large numbers" vs "large numbers" make such a big difference in Python vs JS [15:40:46] But the gcd calculation would be optimised in Python’s Fraction implementation. (re @vrandecic: No, I see they are much smaller, but I am surprised that "very large numbers" vs "large numbers" make such a big difference in P...) [19:19:13] Hmm, general Python failure on Wikifunctions, timing out in orchestration before not returning a String etc Z29092 [19:27:20] I’ve added a comment to *T406848* [19:27:21] Will raise new ticket later, if required. [20:45:46] *T408638* (re @Al: I’ve added a comment to T406848 [20:45:46] Will raise new ticket later, if required.) [20:51:16] noted, I already sent a message to the team, they're investigating (re @Al: I’ve added a comment to T406848 [20:51:16] Will raise new ticket later, if required.) [20:51:54] I'll keep you posted (or someone from the team will) [21:49:43] Fix scheduled for deployment at 00:00 UTC (re @Al: T408638) [22:10:47] Good to get rid of it, but I'm confused because one of the tests I did in my browser was to delete the entire content of the function and return (1.0); which also errored (not due to a different value). Anyway, I'm glad you've all got it working! That's another one off my long term hit list. (re @vrandecic: once this was commented out, Z24537 now passes the JavaScript [22:10:47] implementation!) [22:19:51] Maybe both were required at once. (re @Al: The gcd function is recursive, so that might blow the call stack, I suppose 🤔 The iterative form in Z14707 succeeds in finding n...) [22:30:12] I think so. The converter to code was failing anyway, as with Z20121, so it didn’t matter what the code was. But once the converter was working properly, the debug was able to cause a timeout. (re @u99of9: Maybe both were required for success) [22:51:50] (T408564, by the way) (re @Al: I think so. The converter to code was failing anyway, as with Z20121, so it didn’t matter what the code was. But once the conver...)