[00:37:20] Z22430 has a failing test for Z19293 but when used for the result validation in Z22443, both implementations pass 🤷‍♂️ (re @Al: I suppose we could try wrapping Z21613? I don’t really approve of creating these test-only functions, but they’re not completely...) [00:53:44] Tricky. Z22445 also passes, even though it is doing almost exactly the same thing as the failing test at Z22438 (re @Al: Z22430 has a failing test for Z19293 but when used for the result validation in Z22443, both implementations pass 🤷‍♂️) [01:03:33] I think there is a clue in Z22435. The python implementation fails for a different reason (it just gets the wrong answer). I've put in some debugs which show differences between language representations. [01:07:02] "ZObject,Z11K2:colour>" (re @u99of9: I think there is a clue in Z22435. The python implementation fails for a different reason (it just gets the wrong answer). I've ...) [01:07:20] "ZObject,Z11K2:colour>" (re @u99of9: I think there is a clue in Z22435. The python implementation fails for a different reason (it just gets the wrong answer). I've ...) [01:09:47] One is a reference to actual British English. The other is a language object that has the same key values as that reference? [01:29:02] Yes, I don’t think ZReference objects are supposed to go to the evaluator. Aren’t they supposed to be “normalized”: [01:29:03] “For the processing of ZObjects by the evaluator, all ZObjects are turned into the normal form described above. The normal form doesn't rely on any implicitness regarding whether to interpret a string value as a Z6/String or a Z9/Reference, but they are all expressed as explicit ZObjects.” [01:29:04] [[Wikifunctions:Function model#Normal form]] (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?) [01:29:45] That's not what "normalized" means IIRC (re @Al: Yes, I don’t think ZReference objects are supposed to go to the evaluator. Aren’t they supposed to be “normalized”: [01:29:46] “For the p...) [01:31:51] Normalized is {"Z1K1": "Z40", "Z40K1": "Z41"} vs {"Z1K1": {"Z1K1": "Z9", "Z9K1": "Z40"}, "Z40K1": {"Z1K1": "Z9", "Z9K1": "Z41"}} [01:32:13] It is not that all references don't exist but that references are not expanded [01:33:26] Normal is all expanded, canonical is not expanded [01:34:48] Z2s on wiki are canonical, when sent to the orchestrator is normal? IIRC [01:35:52] That much, I agree with. And the Function Model says that the evaluator gets only normal-form objects. It is the orchestrator that converts canonical to normal. (re @Feeglgeef: Normal is all expanded, canonical is not expanded) [01:36:02] So is the orchestrator, or the python engine, ever supposed to see this? (with ZReference) (re @u99of9: "ZObject,Z11K2:colour>") [01:36:42] Yes that sounds right (re @Al: That much, I agree with. And the Function Model says that the evaluator gets only normal-form objects. It is the orchestrator th...) [01:37:24] Both referenced and deferenced is correct (re @u99of9: So is the orchestrator, or the python engine, ever supposed to see this? (with ZReference)) [01:37:42] Orchestrator yes, evaluator no (as I understand it). (re @u99of9: So is the orchestrator, or the python engine, ever supposed to see this? (with ZReference)) [01:37:56] I don't think that's right (re @Al: Orchestrator yes, evaluator no (as I understand it).) [01:38:39] AFAICT references shouldn't necessarily be resolved, that would be problematic with identity keys [01:38:49] As usual, I have no idea. But if Al is correct, then this is a smoking gun for (one of) the bugs that has been troubling us. [01:40:49] If the python evaluator receives one of each and is asked to say whether they are equal, it cannot do this? That would sound like a bad design? (re @Feeglgeef: Both referenced and deferenced is correct) [01:42:09] Actually yeah that would be unideal. (re @u99of9: If the python evaluator receives one of each and is asked to say whether they are equal, it cannot do this? That would sound lik...) [01:42:30] So we think this is worth pitching as a bug report? [01:43:28] Yeah, not sure if this is ideal or not, would like to hear what Cory thinks here [01:49:53] Well, it is a bug, whether or not we understand what the cause is… having a ZReference floating about helps to explain why the same function produces different results according to its placement. It is likely (?) that the ZReference gets de-referenced at some point to an explicit object (per the Function Model) and is accordingly comparable to some other object (that is [01:49:53] not a r [01:49:54] eference). (re @u99of9: So we think this is worth pitching as a bug report?) [02:00:00] Thanks both! T386426 [02:00:33] The function model says nothing about that (re @Al: Well, it is a bug, whether or not we understand what the cause is… having a ZReference floating about helps to explain why the s...) [02:00:39] But otherwise yeah [03:31:43] Have we grown out of test.wikifunctions? In the last month, there were a handful of system edits, a userpage change, and a little friendly vandalism. I went there because I noticed some phab tasks about trying to fix it. But I don't see the point. IMO we're all still new enough to WF that the main platform is still always a bit experimental, and I don't see many [03:31:43] newcomers being shut down and sent to test elsewhere. Are there good reasons to keep investing in it? : https://tools-static.wmflabs.org/bridgebot/dac6aa8f/file_68602.jpg [03:58:36] Probably for the same reason we still have Test Wikipedia: to test new features in a production-like environment before exposing to a wider audience, which will matter more as Wikifunctions matures more [03:59:27] But new features aren't tested there (re @harej: Probably for the same reason we still have Test Wikipedia: to test new features in a production-like environment before exposing...) [07:34:26] Apologies. I was being bold given the small cost of fixing it. Would this be the discussion about the type's structure, I would have made more time and be less bold. (re @Feeglgeef: Nobody gave me enough time to respond) [07:35:30] I've put my opposition on-wiki (re @vrandecic: Apologies. I was being bold given the small cost of fixing it. Would this be the discussion about the type's structure, I would ...) [07:44:52] Noting that this would be solved by making Z60 an Enum. Maybe something to consider as I've seen quite a few problems that would be solved in this way, and I would very much support it (re @u99of9: "ZObject,Z11K2:colour>") [09:04:49] How do I tell if a type is an enum? Is it when it has a key that is both the identity and has the same type as the type we are defining? [09:11:19] If you remember any, I'm interested in other types of problems that an enum would solve. I'm still undecided about what I will propose for chemical elements (for which I think the atomic number is the strongest identity of all). (re @Feeglgeef: Noting that this would be solved by making Z60 an Enum. Maybe something to consider as I've seen quite a few problems that [09:11:19] would...) [09:24:41] These should be the objects with identity keys: [09:24:42] https://www.wikifunctions.org/w/index.php?fulltext=1&ns0=1&ns4=1&profile=advanced&search=%3A+%22Z3K4+Z1K1+Z40+Z40K1+Z41%22+OR+%22Z3K4+Z41%22&title=Special%3ASearch [09:24:43] I don’t know whether it is more complicated than that, but I’m not convinced that (adding or) making Z3K4: True has magical powers. (re @u99of9: How do I tell if a type is an enum? Is it when it has a key that is both the identity and has the same type as the type we are d...) [09:49:43] This says "Some types, such as string or numbers, do not need an additional key, since their value is their identity." So why isn't Z13518K1 set as an identity key? (and how would that be possible for an integer, where two keys are needed to define their value?) (re @Al: That boils down to [[Wikifunctions:Representing identity]] (or, if it doesn’t, it should). I [09:49:43] explored a ligh [09:49:43] tweight alternative ...) [09:49:57] Why don’t you propose both/either? A third option would be a “Wikidata enum”. The risk is that the decision turns on usability in the Wikifunctions interface rather than integration with Wikipedia. Presumably your proposed conversion to code would be to the same representation, whatever option we decide upon. Having a single converter per type is a limitation that [09:49:57] suggests [09:49:58] to me that parallel types might be appropriate. (re @u99of9: If you remember any, I'm interested in other types of problems that an enum would solve. I'm still undecided about what I will p...) [09:53:18] I’ll get back to you… 😎 (re @u99of9: This says "Some types, such as string or numbers, do not need an additional key, since their value is their identity." So why is...) [09:59:27] I'm no longer worried about linking to Wikidata, because I'm comfortable that a mapping function can get the QID from the atomic number. I lean toward thinking of it like a natural number, so I'm quite tempted to go without enum. But unlike a natural number, the normal ways of looking it up (e.g. "Caesium") are unpredictable, and different in every different language [09:59:28] (hence the i [09:59:28] nterface is a concern). Many of those labels are best stored, and already readily available on Wikidata, but that would be hard to build into the interface here! I've never thought about parallel types - to be honest it sounds super complicated, but I'll need to think further about it. [10:53:27] Yes, I think you are right! (re @u99of9: Am I right that this is the expected behaviour? Z22413) [10:54:02] fixed [13:07:37] Hallo [13:07:48] There's a new translatable message: "Pages with calls to Wikifunctions that result in a systems error" [13:08:07] Is it really supposed to be "systems"? Perhaps it's better to write "system"? [14:03:03] @amire80 had mentioned something about a Z60 not being in reference form and that being unideal (re @u99of9: If you remember any, I'm interested in other types of problems that an enum would solve. I'm still undecided about what I will p...) [16:05:39] I’ll cast an en-gb vote for “system error”, although I’m not clear how we distinguish between types of error, unless it just means Z5/error rather than an apparently erroneous result. (re @amire80: Is it really supposed to be "systems"? Perhaps it's better to write "system"?) [18:18:37] @vrandecic I've created a new type converter for the Kleenean type, Z22464, with error handling as the original returns a really ugly and hard-to-understand Z560. Hopefully should be uncontroversial [18:20:31] Ideally this would be added to all type converters [18:21:24] The only issue is that it can't be translated. For this reason I think it might be beneficial to allow functioneers to create ZErrors for translation purposes [18:22:57] Perhaps we could create a Type converter Enum output error or something [18:49:11] that looks great. I've been bold and made the change. (re @Feeglgeef: @vrandecic I've created a new type converter for the Kleenean type, Z22464, with error handling as the original returns a really...) [18:49:24] Thanks! [18:51:16] https://tools-static.wmflabs.org/bridgebot/616edd10/file_68616.jpg [18:51:23] Looks to be working [18:52:41] It may be beneficial to add this to the other enums by just changing the type converter instead of creating a whole new one [19:00:12] I can disconnect the converters, let you work on them, and then connect them again. Whenever we're both online. [19:00:28] That would be ok (re @vrandecic: I can disconnect the converters, let you work on them, and then connect them again. Whenever we're both online.) [19:00:58] just let me know which one and when, and if I am available, I'll do that [19:02:02] Could you do the month ones now? [19:03:59] Z16098 is disconnected [19:04:36] Z16927 is disconnected [19:08:07] Done here (re @vrandecic: Z16098 is disconnected) [19:11:42] Done with the Igbo ones. [19:12:09] The capitalization of "gregorian" for the messages should be changed actually [19:13:11] Reconnected [19:13:15] Actually can you disconnect both of the gregorian ones again? [19:13:49] disconnected Z16098 [19:14:55] Should be ok now? [19:16:31] connected again [19:18:31] thanks! [19:18:48] The python ones need to have the string wrapped in Exception [19:19:00] After throw [19:20:04] like this? raise Exception("Python...") [19:20:15] Yes (re @vrandecic: like this? raise Exception("Python...")) [19:20:52] https://www.wikifunctions.org/wiki/Z16135?uselang=en&diff=prev&oldid=165732 ? [19:21:13] Yes (re @vrandecic: https://www.wikifunctions.org/wiki/Z16135?uselang=en&diff=prev&oldid=165732 ?) [19:21:24] done for both [19:22:42] Both JS are working correctly [19:25:47] Both python seem to be too [19:26:30] and python? [19:26:45] Seem to be working (re @vrandecic: and python?)