[00:02:30] After removing another ghost, now the problem seems limited to two test failures in Z14101. I've disconnected it, but I can't see a problem. (re @u99of9: Hmm, arguably even worse!) [02:22:08] I made a copy of this which works fine: Z27037. I have no idea what's going wrong with the original Z14101 (re @u99of9: After removing another ghost, now the problem seems limited to two test failures in Z14101. I've disconnected it, but I can't se...) [02:55:35] Ah, got it. I had to nudge the actual composition itself to refresh the cache. now all clear. (re @u99of9: I made a copy of this which works fine: Z27037. I have no idea what's going wrong with the original Z14101) [08:29:50] Thanks for the disentangling! There seems to be a remaining issue with Z13740. The code implementations were mostly failing with Z503. I nudged the Python but left JavaScript Z14040 in case you wanted to check it out. It reminds me how inconvenient *T373607 *can be, so perhaps we might leave it as an example and add it to the ticket? (re @u99of9: Ah, got it. I had to [08:29:50] nudge the ac [08:29:50] tual composition itself to refresh the cache. now all clear.) [08:48:06] (I think it should be a Z504 if the problem is that a “connected” test or implementation is a reference to a non-existent Z2.) (re @Al: Thanks for the disentangling! There seems to be a remaining issue with Z13740. The code implementations were mostly failing with...) [13:40:43] I've added a note at that phab, and won't touch it for now. But I won't be able to hold off touching it if the bug report lasts for another year... (re @Al: Thanks for the disentangling! There seems to be a remaining issue with Z13740. The code implementations were mostly failing with...) [13:50:42] So now that we've got the composition mostly sorted, I'd still like to do this faster with code. So my question here is the converter to code is actually converting a quantity. Inside the object it creates it can have keys for amount, upper and lower. Why can't some of these have a value None (and therefore not have 3 sub-keys)? That's my understanding of what Z25784 [13:50:42] is trying to [13:50:43] do. (re @Al: Okay. I’ll leave it at: surely the converters to code will fail if the “rational number” doesn’t have three keys. So I don’t thi...) [14:11:10] Looks to me like it should be adding None into the dictionary, so the argument is not None, only its value. Does that work? (re @u99of9: So now that we've got the composition mostly sorted, I'd still like to do this faster with code. So my unclarity with what you s...) [14:14:13] So you’d test for None before trying to assign the numerator and denominator? (re @Al: Looks to me like it should be adding None into the dictionary, so the argument is not None, only its value. Does that work?) [14:22:17] Your Python looks okay to me once I remember which K is which 🙄 (re @Al: So you’d test for None before trying to assign the numerator and denominator?) [14:25:39] I think the problem is that the converters assume that voids are passed to the converter in the canonical representation, while in reality they are for some reason already converted to null or None (proof: Z26297) (re @u99of9: So now that we've got the composition mostly sorted, I'd still like to do this faster with code. So my unclarity with what you s...) [14:47:43] Conversion to {"Z1K1": {"Z1K1": "Z9", "Z9K1": "Z21"} seems more likely, and that would appear not to be handled as “void”. (re @dvd_ccc27919: I think the problem is that the converters assume that voids are passed to the converter in the canonical representation, while ...) [14:53:00] Could also be true, but I think that the debug log for Z26297 (in particular look the testcase Z27041) is strong evidence for convertion to null (unless it's typed lists that behave very weirdly) (re @Al: Conversion to {"Z1K1": {"Z1K1": "Z9", "Z9K1": "Z21"} seems more likely, and that would appear not to be handled as “void”.) [15:01:46] Typed lists definitely behave weirdly on occasions! But here I think it’s correct (although I was looking at the Python converter). (re @dvd_ccc27919: Could also be true, but I think that the debug log for Z26297 (in particular look the testcase Z27041) is strong evidence for co...) [15:03:14] For Python the situation should be the same (with None instead of null) (re @Al: Typed lists definitely behave weirdly on occasions! But here I think it’s correct (although I was looking at the Python converte...) [15:14:00] Yes, but an initial debug in Z25997 gives no output for tests like Z26852, just a Z24 and Z511. To me, that suggests that the failure occurs before the Python is called, suggesting an error in conversion to code. [21:31:15] Not sure this is relevant, but it’s baffling. I tried inspecting an unconverted Wikifunctions quantity in an untyped list and Python says: [21:31:16] "ZObject>,Z19677K2:ZObject,Z19677K3:ZObject>,Z6010K3:ZObject 'Z1967 [21:31:17] 7'},Z19677K1:ZObject>,Z19677K2:ZObject,Z19677K3:ZObject>,Z6010K4:ZObject>" [21:31:19] So where’s that “Z6010K1:None” coming from? It occurs if K1 or K2 is set to void but not when K3 is void (although that is still set to None rather than being a ZObject) 🤷‍♂️