[00:51:14] is it possible to write a tester to check that a function results in an error for a certain input? [04:00:08] No, that's not possible yet. That's something we need to add (basically something like Java's catch). [04:02:34] I was mistaken, typed lists of natural numbers are not supported yet. We need to work on that to make it work. It'll happen, but doesn't work yet. Thanks for raising this! (re @Al: Are Natural numbers in a Typed list not working? I tried https://www.wikifunctions.org/view/en/Z13560 but it doesn’t even return...) [04:58:11] Can anyone spot the issue in the (failing) second test here: Z13721? The output and expected output seem identical, although there is a note about hitting a time limit in the orchestrator: : https://tools-static.wmflabs.org/bridgebot/b33c31a7/file_58301.jpg [05:00:51] Oh, I just read the thread above. Perhaps this is related to support for typed lists of natural numbers? But the error I'm getting is very different to Al's [05:46:55] It's surprising that it provides a result but yet fails the time limit [05:50:05] I'm also surprised you are expecting and getting a typed list of number, and not a list of objects [05:59:46] To be honest I never really know what I'm going to get :) (re @vrandecic: I'm also surprised you are expecting and getting a typed list of number, and not a list of objects) [06:00:50] It seems to have settled on the time limit now: : https://tools-static.wmflabs.org/bridgebot/4158abdf/file_58302.jpg [06:03:18] I changed my "expectation" after I saw the first lot of output: https://www.wikifunctions.org/w/index.php?title=Z13723&diff=85872&oldid=85870 (re @Toby: To be honest I never really know what I'm going to get :)) [06:05:09] Thanks for finding these cases. Would you mind capturing that in a bug report? [06:07:44] At the heart of it, I don't know how Python decides what type to make the list when it gets a line like this (where the if and else could have different types): new_list = [lookup_dict[i] if i in lookup_dict else i for i in Z13717K1] return new_list (re @Toby: To be honest I never really know what I'm going to get :)) [06:09:00] I'll try... but maybe the answer is just that my python is bad? (re @vrandecic: Thanks for finding these cases. Would you mind capturing that in a bug report?) [06:17:58] T359500 (re @vrandecic: Thanks for finding these cases. Would you mind capturing that in a bug report?) [06:20:24] BTW, this was motivated by the recording of the previous volunteer's corner where you went searching for a "map" function to do a whole set of character replacements without specially coding the python each time. (re @wikilinksbot: Z13717K1 – replace elements of list according to key-value lookup lists) [06:20:52] Yay! [07:43:10] Ah, well… Thanks for getting back to me and keep up the good work! (re @vrandecic: I was mistaken, typed lists of natural numbers are not supported yet. We need to work on that to make it work. It'll happen, but...) [08:50:35] okay, thanks! (re @vrandecic: No, that's not possible yet. That's something we need to add (basically something like Java's catch).) [09:53:44] You and Python both! [09:53:45] [09:53:47] It kinda makes sense, though… The orchestrator doesn’t have to worry about handling a typed list of Natural numbers until after the evaluation of the function (because your list is a list of objects). The Python code doesn’t know this, it just sees a list filled with integers and dynamically types it as such (I guess). Then the evil occurs. Python’s int type for the list [09:53:48] is translated into a Natural number type for the Typed list before the results are compared. The comparison then times out trying to handle the Typed list of Natural numbers 🙄 [09:57:56] https://t.me/Wikifunctions/13303 That was for you but it lost its “reply-iness” 😏 (re @Toby: To be honest I never really know what I'm going to get :)) [10:02:04] I'm getting out of my depth, aren't I? Is there anything I can do about this? (re @Al: You and Python both! [10:02:05] [10:02:06] It kinda makes sense, though… The orchestrator doesn’t have to worry about handling a typed list of Natura...) [10:05:32] Here, you could avoid having all elements as Natural numbers, but I think the problem is not yours, in general… (re @Toby: I'm getting out of my depth, aren't I? Is there anything I can do about this?) [10:31:36] https://www.wikifunctions.org/view/en/Z13725 tends to confirm my hypothesis. I’ll comment on Phabricator. (Z13725) (re @Toby: I'm getting out of my depth, aren't I? Is there anything I can do about this?) [10:45:22] Please see https://t.me/Wikifunctions/13303 (re @vrandecic: It's surprising that it provides a result but yet fails the time limit) [10:45:34] Thanks. Can I add items the expected result list in Z13725? [10:49:09] Please see my comment on Phabricator. I *think* you’ll struggle to get any equality function to work if the list contains a Natural number. (re @Toby: Thanks. Can I add items the expected result list in Z13725?) [10:50:10] Ok I'll have a go. I guess my point is that I don't see how an incomplete test evidences your assertion on the Phabricator ticket. [10:55:26] So I'd leave it in the state it is now. Again it show identical expected and actual results, with a timeout. : https://tools-static.wmflabs.org/bridgebot/0130059c/file_58309.jpg [10:58:24] Good point. I think it only became incomplete when I changed the type… But: “Actual result: [ "Z13518", { "Z1K1": "Z13518", "Z13518K1": "3" }, { "Z1K1": "Z13518", "Z13518K1": "2" } ]” [10:58:24] [10:58:26] The function returns the correct result if you try it, but I can’t get the Test case to pass. (re @Toby: Ok I'll have a go. I guess my point is that I don't see how an incomplete test evidences your assertion on the Phabricator ticke...) [19:57:32] To clarify (for anyone not looking at Phabricator *T359500*). After further investigation, I’ve concluded that this is not something the Python code does. It is also not specific to the Natural number type; it also happens with Booleans (but that kind of list works, so the consequences are much less apparent). (re @Al: You and Python both! [19:57:33] [19:57:35] It kinda makes sense, though… The orchestrator doesn’t have to worry about handling a typed list of Natura...) [22:57:42] It turns out functioneers can change the argument types of an existing function, as long as we disconnect the implementations first. I just did this at Z12427, and it seems to work. [23:22:21] Yes, that should work. If you don't disconnect the implementations (and tests), it should automatically disconnect them. These are fragile changes that can have some long ranging, not directly observable consequences, so Q65089008 [23:32:07] Agreed. In particular, it can't tell you which compositions rely on the function and therefore need to change. But I imagine that those of us who wrote compositions of "(!)" functions were well aware that they may break. I've updated mine from yesterday: https://www.wikifunctions.org/wiki/Z13720?uselang=en&diff=prev&oldid=86683 [23:34:09] (In future if this kind of type conversion happens more often, it would help to have a "what links here" special page) [23:36:56] For anyone else who wants to try this, the arguments or validators in the tests that were strings need to change to numbers, but at first they look correct. You need to click "literal natural number", and then it blanks the original value and gives you an input box for the number. [23:38:00] The Python functions often just need to remove the str() or int() wrapper. Javascript wrappers still seem useful, because if you remove them, it can't deal with the BigInt anyway. [23:40:42] I just set a sitelink from Q47577 to Z13835 and it felt extremely satisfying