[02:47:43] One feature that would speed this up enormously would be a function calling for just the claims with a particular predicate, rather than the entire item. (re @David: Thanks for calling this out. I've added this case to a list (currently just in a team document AFAIK) of Wikidata-object-relate...) [02:48:21] I don't think it's too late to change the keys now, but please don't leave it too long! (re @David: Hey, thanks for pointing that out! That was an unintentional oversight, and "my bad". When I wrote the code that creates insta...) [02:55:58] @vrandecic please can you add Z14392 as the equality function for Z11. I can't imagine this one being controversial. [04:02:35] I think I've hit a similar problem in Z23166, check the debugs. (re @u99of9: One is a reference to actual British English. The other is a language object that has the same key values as that reference?) [09:11:41] welcome Tofu [09:13:40] I think the language representations here are both valid, just not comparable in code (because ‘Z1002’ cannot be equal to ‘en’, for example). (re @u99of9: I think I've hit a similar problem in Z23166, check the debugs.) [09:13:41] What? Welcoming a food? (re @u99of9: welcome Tofu) [09:59:49] any idea why https://www.wikifunctions.org/view/fr/Z22300 doesn't seem to be working? (it's the same principle as https://www.wikifunctions.org/view/fr/Z12441 which is working...) [10:00:21] (I’m using “valid” quite precisely here: the code objects are valid reference objects rather than invalid (?) ZReference objects. Except as the identity of a persistent object, I can’t see that it makes any sense to pass a reference to a Z60 into code.) (re @Al: I think the language representations here are both valid, just not comparable in code (because ‘Z1002’ cann [10:00:21] [10:00:22] ot be equal to ‘en’, ...) [10:53:37] So if I understand you right: You also can't see a way of getting this to work? The language reference coming from the Wikidata claims are causing an impossible problem? So I file a new Phab for David , because this issue is somehow different from T386426? (re @Al: (I’m using “valid” quite precisely here: the code objects are valid reference objects rather than [10:53:37] invalid (?) [10:53:37] ZReference objects...) [11:07:10] I also can't see a problem with what you've built. I went to make a test in "contains", but found a similar failing one already there Z20217. If we can understand or fix that, I think your new case will be similar. (re @Nicolas: any idea why https://www.wikifunctions.org/view/fr/Z22300 doesn't seem to be working? (it's the same principle as https://www.wi...) [11:48:19] Actually, that test seems to be associated with the wrong function. I'll fix that in a minute. Instead maybe Z20235 is closest. [12:00:08] O I created this! (re @u99of9: Actually, that test seems to be associated with the wrong function. I'll fix that in a minute. Instead maybe Z20235 is closest.) [12:02:08] Nice. I've moved your Z20217 to its home function, where it now passes! (re @cvictorovich: O I created this!) [12:02:30] See its history (re @u99of9: Nice. I've moved your Z20217 to its home function, where it now passes!) [12:03:47] You had it right at first! Do you remember why you moved it? (re @cvictorovich: See its history) [12:04:12] Didn’t move it (re @u99of9: You had it right at first! Do you remember why you moved it?) [12:05:04] https://www.wikifunctions.org/w/index.php?title=Z20217&diff=139728&oldid=139727 this edit moved it (re @cvictorovich: Didn’t move it) [12:09:50] Anyway, back to this one instead. I've added some debugs in the Javascript implementation Z12711 which seem to show some differences in how many backslashes are used for character escaping. Al I think you may be best to look into this. It looks like a similar failure for Z20216 and Z20235 (re @wikilinksbot: Z20235 – claims in L-fr:"trahir" include conjugation=group2) [12:17:01] Well, yeah, it’s not the same issue, but “doing languages right” may be the common solution! I think we call those separate bugs and let the team worry about the solution(s). In the meantime, you’d have to build a language lookup in every code function, because we can’t change the function specification to pass a Wikifunctions reference rather than the dereferenced Z60 [12:17:01] [12:17:01] (unless we can, somehow). (re @u99of9: So if I understand you right: You also can't see a way of getting this to work? The language reference coming from the Wikidata ...) [12:29:29] Yeah, but there’s a complicating bug as well, which is a variation of *T373607*. When a function should return a Boolean, any result other than True is deemed to be False. I believe Z22283 is failing too; it just appears to pass (because “not True” is interpreted as False, which is what is expected). (re @u99of9: Anyway, back to this one instead. I've added some debugs in [12:29:29] t [12:29:29] he Javascript implementation Z12711 which at first look seem to sho...) [12:32:50] Does this make sense? T388117 (re @Al: Well, yeah, it’s not the same issue, but “doing languages right” may be the common solution! I think we call those separate bug...) [12:39:14] Interesting. That's from the day of my fourth edit, so I was blissfully unaware until now! But anyway, the last two tests are both supposed to be true, so we need to work on the contains function to deal with these complex type stringifications? (re @Al: Yeah, but there’s a complicating bug as well, which is a variation of T373607. When a function should return a [12:39:14] Boolean, any resu...) [12:40:05] I've subscribed in case it ever gets fixed ;-) (re @Al: Yeah, but there’s a complicating bug as well, which is a variation of T373607. When a function should return a Boolean, any resu...) [12:43:16] Makes sense to me. You might add that the language object in a Z11 is ordinarily converted to its string code (like ‘en’). (re @u99of9: Does this make sense? T388117) [12:45:48] Thanks. Done. 🎃 (re @Al: Makes sense to me. You might add that the language object in a Z11 is ordinarily converted to its string code (like ‘en’).) [12:49:54] is it not just a case of "a broken clock is right twice a day" ? (re @Al: Yeah, but there’s a complicating bug as well, which is a variation of T373607. When a function should return a Boolean, any resu...) [12:51:25] I’m not sure. I think we may get extra escaping in the display of the debugs, but maybe we can clean up before the comparison. (re @u99of9: Interesting. I was blissfully unaware until now! But anyway, the last two tests are both supposed to be true, so we need to wor...) [12:53:06] 🤷‍♂️ If it doesn’t return False, it doesn’t return False! 😎 (re @Nicolas: is it not just a case of "a broken clock is right twice a day" ?) [12:57:21] but in this case, it does return false as expected (for the wrong reason - the function seems to always return false no matter what - but still as expected) (re @Al: 🤷‍♂️ If it doesn’t return False, it doesn’t return False! 😎) [12:58:23] and yes, I know, the output of this function shouldn't be boolean in the first place, but there is no "gender" datatype yet... [13:07:04] Ah, yes… fair point… It’s not looking for masculine so it doesn’t matter that it wouldn’t find it if it were. (re @Nicolas: but in this case, it does return false as expected (for the wrong reason - the function seems to always return false no matter w...) [13:11:08] for the context, I just wanted to try somehting "simple" to see how to retrieve claims for Wikidata Lexemes [13:11:08] but even this "simple" function is already failing and I don't see why... [13:14:31] Yes, we think the function itself is fine; it just relies on a function that takes “equals” literally and is intolerant of inconsistencies (which we shouldn’t have). (re @Nicolas: for the context, I just wanted to try somehting "simple" to see how to retrieve claims for Wikidata Lexemes [13:14:32] but even this "simpl...) [13:34:49] mhh, what part is intolerant exactly? (and why is it broken in one case and not the other? :/ ) (re @Al: Yes, we think the function itself is fine; it just relies on a function that takes “equals” literally and is intolerant of incon...) [13:43:56] Probably Z12696@uselang=fr (but I’m keeping an open mind) (re @Nicolas: mhh, what part is intolerant exactly? (and why is it broken in one case and not the other? :/ )) [13:52:35] For the older function, it’s also broken there now too. The true passes are from January 14th. If you edit source on Z12441, these fail. (re @Nicolas: mhh, what part is intolerant exactly? (and why is it broken in one case and not the other? :/ )) [14:23:28] oh! [14:23:29] bad news but at least it consistent... (re @Al: For the older function, it’s also broken there now too. The true passes are from January 14th. If you edit source on Z12441, the...) [14:46:33] Except Z20217 passes 😵‍💫 (re @Nicolas: oh! [14:46:34] bad news but at least it consistent...) [18:41:49] Yes, thanks! I'll take a look. (re @u99of9: Does this make sense? T388117) [18:45:29] I think the rank might too, at least if the statement comes in a list. (re @David: Yes, thanks! I'll take a look.) [18:49:38] I mean, it appears as a ZReference… (re @Al: I think the rank might too, at least if the statement comes in a list.) [19:29:55] Debugging the debugging took a while. The Z6003K4 formats are different, so no equality can be established. : https://tools-static.wmflabs.org/bridgebot/d4f4a64d/file_68941.jpg [19:54:55] I’ve amended Z12863 to ignore Z6003K4 (at least some of the time) and its failing tests now pass. [20:01:28] Your function is now working. (re @Nicolas: oh! [20:01:29] bad news but at least it consistent...) [21:34:27] Perhaps in the short term it would be easier to provide Wikifunctions.deReference in the evaluator? (re @Al: Debugging the debugging took a while. The Z6003K4 formats are different, so no equality can be established.) [21:43:00] Maybe. I’ve only fixed one implementation of one function. This particular inconsistency will also affect other functions like Z13052 and Z12846, I suppose, but only when only one of the statements comes from a (Wikidata) list (I think). (re @Feeglgeef: Perhaps in the short term it would be easier to provide Wikifunctions.deReference in the evaluator?) [22:16:39] Can you figure out how to ask for a Wikidata list return that is more consistent with what we already had? This sounds different again from the language reference returns. (re @Al: Maybe. I’ve only fixed one implementation of one function. This particular inconsistency will also affect other functions like Z...) [22:21:38] You mean create another ticket? I’m happy to do that. I think we just want a complete absence of ZReference objects, but I’m open to other opinions. (re @u99of9: Can you figure out how to ask for a Wikidata list return that is more consistent with what we already had? This sounds different...) [22:28:10] Yes. I guess it's harder to sign off that they're all gone than to sign off each reported instance. (re @Al: You mean create another ticket? I’m happy to do that. I think we just want a complete absence of ZReference objects, but I’m ope...) [22:30:49] I’ll aim to do that between 12 and 18 hours from now. 😎 [23:07:48] I have set a cunning trap for the wary… If Z12863 finds no match, it scans the input list for a ZReference and emits a Debug for the first it finds. Currently this is triggered only on the two tests that contain Z6003K4s so (a) it works and (b) it is not generally triggered. It also fires for the monolingual text list from the lemmas of L1347 (using Try this function). [23:07:48] (re @u99 [23:07:49] of9: Yes, thanks. I guess it's harder to sign off that they're all gone than to sign off each reported instance.) [23:16:45] Denny's had limited availability this week, so I've just added it. (re @u99of9: @vrandecic please can you add Z23130 as the equality function for Z6096? I can't imagine this one being controversial.) [23:59:03] Thanks David . This one too please. (re @u99of9: @vrandecic please can you add Z14392 as the equality function for Z11. I can't imagine this one being controversial.)