[02:03:50] <wm-bb>	 <u99of9> It seems like a bug that the interface cannot see the result validation comparison object in Z27294 because it is a lexeme sense. Even in edit mode! Has this already been reported?
[02:04:11] <wm-bb>	 <u99of9> https://www.wikifunctions.org/view/en/Z27294
[02:10:39] <wm-bb>	 <u99of9> @dvd_ccc27919 thanks for taking the lead on adapting functions for error handling. I've already found the results useful in debugging. It will take me a while to learn how to do it myself, but I want to express that I very much appreciate that you're doing so much for us!
[02:43:04] <wm-bb>	 <u99of9> The system is not allowing me to create a novalue test with an empty value at Z28297 : https://tools-static.wmflabs.org/bridgebot/0cf5bc4b/file_73888.jpg
[10:53:05] <wm-bb>	 <Al> Tricky. I don’t see a way forward at the moment. I think I already failed trying to upgrade Z23723 to support the new keys. There, the objects end up not being comparable because the keys are simply omitted in the Wikidata fetch and I’ve found no way to emulate that. Short answer, I think: for the objects to be comparable you need to omit the key, but you can’t 🤷‍♂
[10:53:05] <wm-bb>	 <clipped message>
[10:53:06] <wm-bb>	 <Al> ️ (re @u99of9: The system is not allowing me to create a novalue test with an empty value at Z28297. Do I need to put in a nullary void in the ...)
[11:35:25] <wm-bb>	 <Al> Correction: the value is set to void but the optional keys are omitted. (re @Al: Tricky. I don’t see a way forward at the moment. I think I already failed trying to upgrade Z23723 to support the new keys. Ther...)
[12:49:44] <wm-bb>	 <Al> Z28315. The omitted keys are in Z6003, not Z6007. Do we always get a spurious Z560 when correctly evaluating to Z24? I’ll file a ticket if I can’t find one. (re @u99of9: The system is not allowing me to create a novalue test with an empty value at Z28297. Do I need to put in a nullary void in the ...)
[12:54:25] <wm-bb>	 <u99of9> Yes I think that's common behaviour. Handling voids properly is still in its infancy. (re @Al: Z28315. The omitted keys are in Z6003, not Z6007. Do we always get a spurious Z560 when correctly evaluating to Z24? I’ll file a...)
[14:53:44] <wm-bb>	 <carbon_starlight> Can you provide more information? What wiki are we talking about? (re @SvetaT23: Hi. Is someone here a Telegram bot coder, who could help me as a guide and co-maintainer, for a bot that posts updates from on-w...)
[15:03:42] <wm-bb>	 <Al> What happened to “Actual results”? Are they never visible now?
[21:42:59] <wm-bb>	 <Al> I’m seeing significant performance issues with Python implementations timing out with trivial operations like adding 1 + 1 in Z13573 🤔 In fact, a simple return fails in Z24138:
[21:43:00] <wm-bb>	 <Al> *Duration*
[21:43:01] <wm-bb>	 <Al> 9026 ms
[21:43:03] <wm-bb>	 <Al> Orchestration: 
[21:43:04] <wm-bb>	 <Al> Duration: 9026 ms
[21:43:06] <wm-bb>	 <Al> Start time: 10 seconds ago
[21:43:07] <wm-bb>	 <Al> End time: 1 second ago
[21:43:09] <wm-bb>	 <Al> Evaluation: 
[21:43:10] <wm-bb>	 <Al> Duration: 9000 ms
[21:43:12] <wm-bb>	 <Al> Start time: 10 seconds ago
[21:43:13] <wm-bb>	 <Al> End time: 1 second ago
[21:43:15] <wm-bb>	 <Al> *CPU usage*
[21:43:16] <wm-bb>	 <Al> 81.22 ms
[21:43:18] <wm-bb>	 <Al> *Memory usage*
[21:43:19] <wm-bb>	 <Al> 261.8 MiB
[21:56:45] <wm-bb>	 <Al> *T404797*
[22:50:03] <wm-bb>	 <u99of9> Same, thanks for reporting. (re @Al: I’m seeing significant performance issues with Python implementations timing out with trivial operations like adding 1 + 1 in Z1...)