[00:17:49] Tricky blighters, coincidences! Thanks for taking a look. The first time I had the problem it was using list equality with string equality… https://www.wikifunctions.org/wiki/Z22850?uselang=en&oldid=170580 (but that function has changed since, so the actual results are no longer equal to the expected results) 🤷‍♂️ I’ll take another look in the morning. (re @u99of9: [00:17:49] [00:17:49] I'm not there yet, but I think it's nothing to do with "OR". Instead I think it's either something about the way lists of string...) [00:30:19] Z23092 has a list within item 1 of the list, so I’m not sure it’s connected. The string “test” is not a subset of the list containing only a list (containing the string), so the expected result should be False, like the actual result. (re @u99of9: I'm not there yet, but I think it's nothing to do with "OR". Instead I think it's either something about the way lists of [00:30:19] string...) [00:34:14] Oops, yes, you're right. I've fixed that now, and it passes: Z23092 (re @Al: Z23092 has a list within item 1 of the list, so I’m not sure it’s connected. The string “test” is not a subset of the list conta...) [00:36:10] Another possibility I have in mind is some kind of string escaping of the " characters. [09:19:38] 1575 [09:19:47] 7575 [11:30:52] Welcome A [19:05:57] We now have a workaround. I think you’ll like it: Z23106. Just removing spaces didn’t seem to work, so you might be right about it being an inconsistent escaping issue. (re @u99of9: I'm not there yet, but I think it's nothing to do with "OR". Instead I think it's either something about the way lists of string...) [21:43:13] Nice! I suppose that raises the question: Have you checked if the function is actually accidentally returning some kind of special character which gets converted to a normal character when the result is displayed? Perhaps a special space character or similar? (re @Al: We now have a workaround. I think you’ll like it: Z23106. Just removing spaces didn’t seem to work, [21:43:14] so you mi [21:43:14] ght be right about ...) [22:16:55] No. I’m not sure how I would set about that. Some sort of Unicode ROT1, perhaps? 🤔 Or maybe just removing all Latin alphanumerics? (re @u99of9: Nice! I suppose that raises the question: Have you checked if the function is actually accidentally returning some kind of speci...) [22:25:44] Maybe something with Z22717 (re @Al: No. I’m not sure how I would set about that. Some sort of Unicode ROT1, perhaps? 🤔 Or maybe just removing all Latin alphanumeric...) [22:27:18] Then Z19198? [22:33:32] That would hit the recursion limit. Maybe a simple string length for starters? (re @u99of9: Maybe something with Z22717) [22:45:29] Yes. This shows a difference. (re @Al: That would hit the recursion limit. Maybe a simple string length for starters?) [22:47:10] When I call Map(string length, Z23072(String, false)) it gives [13,52,107,62] [22:48:18] 🤔 and the first is the same but not the others? (re @u99of9: When I call Map(string length, Z23072(String, false)) it gives [13,52,107,62]) [22:49:26] But when I manually count the output characters displayed on my screen, I get [13, 53, 104, 62] [22:50:03] some higher some lower!?? might be worth checking my manual counts. [22:56:25] Yeah, they’re tricky to count. I’m happy with the first, because I made it 14 for Z80. I’d expect the second to be 51. (re @u99of9: some higher some lower!?? might be worth checking my manual counts.) [22:57:19] in the second element of the list, the first difference seems to be that there is a double-space before the OR (which wouldn't show up in the manual count of the HTML display) [22:58:47] Ah… then I can blame the coder! 😎 (re @u99of9: in the second element of the list, the first difference seems to be that there is a double-space before the OR (which wouldn't s...) [23:01:15] I got to the end of the second element, with that as the only difference. So yes, that difference looks to be due to the double space. (re @u99of9: in the second element of the list, the first difference seems to be that there is a double-space before the OR (which wouldn't s...) [23:02:55] My manual count was wrong - I accidentally counted the start and end quotes, so element 2 should be 51 as you expect. (re @u99of9: But when I manually count the output characters displayed on my screen, I get [13, 53, 104, 62]) [23:06:18] Well I know where that bug comes from. Just looking for similar lapses elsewhere. Thanks for your help! (Handy tool, that new map function…) (re @u99of9: My manual count was wrong - I accidentally counted the start and end quotes, so element 2 should be 51 as you expect.) [23:08:01] Element 3 has 3 double spaces in it too. [23:09:04] Yeah, the joy of reuse! 😏 (re @u99of9: Element 3 has 3 double spaces in it too.) [23:14:58] Of course, I copy-pasted the result strings into the result validation, so the double spaces were presumably absent from the displayed result? Is that an html “feature”? (re @u99of9: in the second element of the list, the first difference seems to be that there is a double-space before the OR (which wouldn't s...) [23:16:44] Yes, html condenses multiple spaces. Since all our error logging, including Wikifunctions.Debug(), is displayed in html, double space errors are exceptionally hard to find! After your fixes, Z23091 now works fine. [23:19:43] We need a version of Z22507 that just returns a Boolean "has multiple spaces" [23:22:32] And maybe an additional marker when a string return is displayed. Only showing up when multiple spaces are being hidden. This could be a useful Phab? [23:24:57] …especially when you don’t know to look for them! Like you, I was just thinking about something like replacing a double-space with something visible before html gets to mangle the result. (re @u99of9: Yes, html condenses multiple spaces. Since all our error logging, including Wikifunctions.Debug(), is displayed in html, double ...) [23:26:23] 7496 [23:26:46] Welcome Johnny