[00:42:19] They were disconnected because they have never been connected (similar to almost all built-ins). That is because the community have not yet been given the functionmaintainer right ([[Wikifunctions:Maintainers]]), and because staff have been too busy or found it hard every time connections have been requested. I won't speak for Nizo, but the reason I want good tests [00:42:19] connected on a [00:42:19] ll built-in functions is to demonstrate the expected behaviour of the function, especially given that we can't see the code. For example, by leaving Z24838 disconnected, we suggest that this is not expected/desired behaviour for this function (but why not??). If it is desired, then just like any other function, I would suggest connecting it, and admitting that our [00:42:19] current (built- [00:42:21] in) implementation is not quite doing everything we hope it will do. (re @David: Thanks for mentioning. Weird; I have no idea why they are disconnected. I've just connected the passing tests, and I'm going to...) [00:48:04] Also, you can certainly connect Z16640 and Z16641. The built-in passes. They are great demonstrations that serialisation from typed lists in code cannot currently achieve what we would need to get rid of the built-in in this space. (re @u99of9: They were disconnected because they have never been connected (similar to almost all built-ins). That is because the [00:48:05] community h...) [00:53:22] More background at [[Wikifunctions:Project_chat/Archive/2024/06#Revisiting_community_"maintainer"_rights]] (re @u99of9: They were disconnected because they have never been connected (similar to almost all built-ins). That is because the community h...) [02:13:25] This one seems unnecessary: Z30548 completes in 3650ms, but when I include rounding and rendering, (which takes 1750ms for a comparable test Z29889) gives me WASI errors at Z30547. (re @u99of9: I'm seeing this error quite often. Does that give any clues about the general issues? Could not acquire WASI runner within time ...) [02:15:13] https://tools-static.wmflabs.org/bridgebot/ca66bef3/file_75988.jpg [05:58:55] Thanks so much for explaining and giving this perspective, which is very helpful! I've connected the remaining 3 tests, as you suggest. Regarding Z24838, I didn't look closely but I believe that is probably another illustration of the problems with comparing statements, which were discussed recently here, and which I hope to work on soon. (re @u99of9: They were [05:58:55] disconnected bec [05:58:55] ause they have never been connected (similar to almost all built-ins). That is because the community d...) [06:26:08] You're probably right, the validator could well be the issue. Coincidentally another built in... (re @David: Thanks so much for explaining and giving this perspective, which is very helpful! I've connected the remaining 3 tests, as you ...) [08:43:45] Also, the first element in the list is Q613883, rather than Q308 🤷‍♂️ (re @u99of9: You're probably right, the validator could well be the issue. Coincidentally another built in...) [08:45:40] Eek, good pickup. (re @Al: Also, the first element in the list is Q613883, rather than Q308 🤷‍♂️) [09:54:47] But still failing after the fix. (re @u99of9: Eek, good pickup.) [10:35:33] But now you have a Z507 in the validation call 🤷‍♂️ (re @u99of9: But still failing after the fix.) [12:04:39] Heads up… This looks like a troubling false positive (https [12:04:39] //www.wikifunctions.org/view/en/Z6801?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z6801%22%2C%22Z6801K1%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z30120%22%2C%22Z30120K1%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q111%22%7D%2C%22Z30120K2%22%3A%5B%22Z6030%22%2C%22Z6035%22%5D%2C%22Z30120K3%22%3A%5B%2 [12:04:40] 2Z60%22%5D%2C%22Z30120K4%22%3A%5B%22Z6092%22%5D%7D%2C%22Z6801K2%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z30120%22%2C%22Z30120K1%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q111%22%7D%2C%22Z30120K2%22%3A%5B%22Z6030%22%2C%22Z6033%22%5D%2C%22Z30120K3%22%3A%5B%22Z60%22%5D%2C%22Z30120K4%22%3A%5B%22Z6092%22%5D%7D%7D) 🤔 A similar comparison with a different [12:04:40] function [12:04:42] (https [12:04:42] //www.wikifunctions.org/view/en/Z29294?call=%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z29294%22%2C%22Z29294K1%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z30120%22%2C%22Z30120K1%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q111%22%7D%2C%22Z30120K2%22%3A%5B%22Z6030%22%2C%22Z6033%22%5D%2C%22Z30120K3%22%3A%5B%22Z60%22%5D%2C%22Z30120K4%22%3A%5B%22Z6092%22%5D%7D% [12:04:42] [12:04:43] 2C%22Z29294K2%22%3A%7B%22Z1K1%22%3A%22Z7%22%2C%22Z7K1%22%3A%22Z30120%22%2C%22Z30120K1%22%3A%7B%22Z1K1%22%3A%22Z6091%22%2C%22Z6091K1%22%3A%22Q111%22%7D%2C%22Z30120K2%22%3A%5B%22Z6030%22%2C%22Z6036%22%5D%2C%22Z30120K3%22%3A%5B%22Z60%22%5D%2C%22Z30120K4%22%3A%5B%22Z6092%22%5D%7D%7D) seems to recognise the differences. I’ll file a ticket later. (re @David: Thanks so much for [12:04:43] explai [12:04:45] ning and giving this perspective, which is very helpful! I've connected the remaining 3 tests, as you ...) [12:33:38] Interesting example. In one sense they are the same item, but in the object sense they're different parts of that item. I can see value in having different functions for each, so perhaps we just need to better describe this one? (re @Al: Heads up… This looks like a troubling false positive 🤔 A similar comparison with a different function seems to recognise the dif...) [12:39:50] In the spirit of connecting tests to describe the behaviour, I've put your example into Z30554 (re @u99of9: Interesting example. In one sense they are the same item, but in the object sense they're different parts of that item. I can se...) [19:08:41] Thanks. I’m having a busy couple of days… I’m not sure how to denote that sort of level-one equality (if that’s what it is). Or is it just returning True when the objects have the same QID? Z29294’s destiny is to return True when both objects have the same canonical form. It would be enough, for example, for two Z12s to have the same set of Z11s, disregarding their orde [19:08:41] [19:08:42] r. That’s some way off, because it’s not clear, from an object’s structure, when a list represents a set. [20:23:53] both test pass now but are disconnected. it's a built in. (re @Al: Heads up… This looks like a troubling false positive 🤔 A similar comparison with a different function seems to recognise the dif...) [22:46:33] Conflating ordered lists and unordered sets will eventually cause headaches. (re @Al: Thanks. I’m having a busy couple of days… I’m not sure how to denote that sort of level-one equality (if that’s what it is). Or ...) [23:05:22] It already does. Order should be irrelevant in a Typed map, given that it’s designed to be accessed by key. But while duplicate keys remain possible, differently ordered lists in maps stop them from being equivalent in practice, unless we return an exception when a key is not unique (unless the associated values are the same). (re @u99of9: Conflating ordered lists and [23:05:22] unordered [23:05:22] sets will eventually cause headaches.) [23:11:43] Thanks, Al! Good points. Regarding T411947 - that's a simple task and i think it's a no-brainer – just ensuring there's always a value present for Z6003K5/qualifiers and Z6003K6/references – in other words, an empty list if there are zero qualifiers or references. I will likely go ahead and do this very soon. I understand your broader point about constructing objects [23:11:43] for [23:11:43] comparison, which probably calls for more discussion – but in the meantime, do you have any concerns about this particular simple change? (re @Al: I note T411947 and will comment there in due course. The problem with testing Wikidata functions is that we are generally preven...) [23:21:22] Yes this is an important issue, but i'm not currently aware of specific cases that are prevented, at least not in the realm of Wikidata entities. Apart from the issues with statements, I'm not aware of specific things that are impossible to capture when constructing an object for comparison. I'm probably just ignorant or forgetting. Please remind me if specific cases [23:21:22] have been recorded. [23:21:22] I think it should be possible to construct matching objects for the partial results coming back from Z6820. I say this because because I think those objects consistently have empty lists for entity-parts that were not requested. But there are many cases and I could be wrong about that. (re @Al: I note T411947 and will comment there in due course. The problem with [23:21:23] testing Wikida [23:21:24] ta functions is that we are generally preven...) [23:22:34] No concerns, no. I think they must be semantically equivalent representations. There will be some test cases that might need fixing, but I would expect that to be achieved by a change to implementations of Z23723, unless we decide to change the test cases themselves. (re @David: Thanks, Al! Good points. Regarding T411947 - that's a simple task and i think it's a [23:22:34] no-brainer – [23:22:34] just ensuring there's alway...) [23:26:10] That is, given that one understand the behavior of Z6820 – which admittedly might call for some additional documentation. (re @David: Yes this is an important issue, but i'm not currently aware of specific cases that are prevented, at least not in the realm of W...) [23:28:31] Also, no rush on this discussion; I recall that you are in a busy phase… (re @David: That is, given that one understands, in detail, the behavior of Z6820 – which admittedly might call for some additional document...) [23:40:28] There is just no option to provide a Wikidata entity object as an argument to a function except as a function call. That is by design, as I understand it. It can be “emulated” by constructing a ZObject in a function implemented in code, but not (I believe) by means of a composition, other than those that ultimately fetch from Wikidata. In other words, when you choose, [23:40:28] say, Wi [23:40:28] kidata item as your object Type, you get a function call and only the function to be called can be changed. (re @David: Yes this is an important issue, but i'm not currently aware of specific cases that are prevented, at least not in the realm of W...) [23:58:50] Oh, right! Thanks for reminding me and clarifying. I sort of knew about that limitation, but I've almost never stumbled across it or struggled with it, personally. (re @Al: There is just no option to provide a Wikidata entity object as an argument to a function except as a function call. That is by d...)