[00:39] *** wayland joined [00:39] *** wayland76 left [00:43] *** johnjay joined [00:54] *** wayland left [00:55] *** wayland joined [01:03] *** rmv left [01:23] after careful reconsideration (sleep), I think it would be useful to be able to inspect state of a supply block somehow [01:29] the question "what exactly is it doing?" would probably require wrapping every single tap into some wrapper [01:49] *** kylese left [01:49] *** hulk joined [02:01] *** vrurg joined [02:03] *** vrurg_ left [02:15] *** hulk left [02:15] *** kylese joined [02:20] *** wayland left [02:20] *** wayland joined [03:03] *** lichtkind_ joined [03:06] *** lichtkind left [03:08] *** wayland76 joined [03:08] *** wayland left [03:11] *** wayland76 left [03:16] *** wayland76 joined [04:26] *** wayland76 left [05:35] *** abraxxa joined [05:36] *** erooke left [05:36] *** abraxxa left [05:37] *** abraxxa joined [05:47] *** Sgeo left [05:50] *** hurufu joined [06:08] *** erooke joined [07:32] I meant something like this (obviously more useful version would have some ring buffer that could be dumped on demand): https://glot.io/snippets/hjzcs17o93 [07:42] *** guifa_ left [07:54] *** dakkar joined [08:08] *** johnjay left [08:21] *** johnjay joined [08:56] *** guifa left [09:45] *** johnjay left [09:46] *** rmv joined [09:46] *** rmv left [09:46] *** rmv joined [09:50] *** rmv left [09:53] *** El_Che joined [10:18] *** wayland76 joined [10:18] simon_sibl: Bug in Set: https://github.com/rakudo/rakudo/issues/6280 [10:19] You need 2026.05 to resolve the bug. [10:20] Probably just bite the bullet and go with Rakubrew. [10:25] 2026.06 is out, with the big fixed (ar least in legacy) [10:27] but 2026.05 for the time being has the "utf8 data over 10k bytes can hang the process if there's invalid bytes in there" bug [10:28] *** johnjay joined [10:28] 2026.06 also has that, no? [10:32] simon_sibl: My mistake -- as lizmat said, you need 2026.06. [10:38] oh, wait, sorry i forgot which month it was [10:39] the bug i meant is only in 06 not in 05 [10:48] ah? it was introduced in 06 ? [10:48] I thought it was much older ? [10:56] the thing introduced in 06 was both an optimization for a long-standing thing, and a bug [10:57] before, it was just causing long waits for GC to be able to start when decoding large buffers to utf8 or utf8c8 [10:57] after the improvement, gc could immediately start while some thread was busy doing that [10:57] tadzik: Thanks for the link to the macros stuff. Interestingly, it says it needs a tree manipulation sysmte, and I'm working on a tree manipulation system for Raku (unrelated to macros, but with the intent that it someday be usable for macros). Amusingly, I suggested a basic tree maipulation system for Perl 6 in about 2002 or so, but I phrased it as being XPath-like, and Larry didn't think at the time that we needed it. I've learned a lot about what I [10:57] call "Data Oriented Programming" (mostly Trees + Tables) since then. [10:57] but unfortunately, if there was invalid bytes in the data, creating an exception while the thread is marked blocked is a bug that hangs the whole process [10:58] m: start { say "starting side-thread"; }; say Buf.new(0xf0 xx 10001).decode("utf8") [10:58] rakudo-moar 1b77a9023: OUTPUT: «starting side-thread␤Malformed UTF-8 near byte f0 at line 1 col 1␤ in block at line 1␤␤» [10:59] having other threads active at the time may prevent the hang; not guaranteed to work [11:00] aruniecrisps: Macros also at https://docs.raku.org/syntax/macros [11:03] c: 2026.06 start { say "starting side-thread"; }; say Buf.new(0xf0 xx 10001).decode("utf8") [11:03] timo, ¦2026.06: «starting side-thread␤«timed out after 10 seconds» «exit signal = SIGHUP (1)»» [11:04] c: 2026.06 start { say "starting side-thread"; }; start { for ^1000 { my @lol = ^100; True }; True }; say Buf.new(0xf0 xx 10001).decode("utf8") [11:04] timo, ¦2026.06: «starting side-thread␤«timed out after 10 seconds» «exit signal = SIGHUP (1)»» [11:04] or not [11:16] *** wayland76 left [11:17] *** wayland76 joined [11:28] *** rmv joined [11:28] *** rmv left [11:28] *** rmv joined [11:32] *** johnjay left [11:33] *** guifa joined [12:10] *** rmv left [12:27] *** johnjay joined [12:50] *** rmv joined [12:51] *** Geth left [13:00] *** abraxxa left [13:23] lo [13:23] 2026-06-27T19:37:14Z #raku-dev <[Coke]> el_che the source release for 2026.06 is done. [13:23] \o? [13:25] oh hai El_Che [13:38] cooking 2026.06 now [13:55] *** rmv left [14:05] *** rmv joined [14:05] *** rmv left [14:05] *** rmv joined [14:33] *** rmv left [14:48] *** rmv joined [14:48] *** rmv left [14:48] *** rmv joined [15:01] <[Coke]> El_Che: if there is a better way to notify you, let me know. :) [15:05] fwiw, I hope to be able to make that more automatic with https://raku.land/zef:lizmat/JSON::RepositoryEvent :-) [15:22] *** wayland76 left [15:22] *** wayland76 joined [15:36] yeah, sometime I forget to check irc [15:42] how would you like to be informed? an email ? [15:42] an SMS ? [15:45] <[Coke]> if it's a public thing, we can add it directly to the release guide, if it's private, we can keep it someplace secret. [15:45] <[Coke]> patrickb: same for you. [15:46] with https://raku.land/zef:lizmat/JSON::RepositoryEvent I'm more thinking more generally, so that people can subscribe to certain events [15:46] like a release tag on rakudo, and decide how they want to be informaed [15:48] anyways... first get a modern Geth working [15:49] I understand the historic name of Geth... but I feel a more modern name / better descriptive name could be useful by now [15:53] [Coke]: For me the issue never was to know about a release, but to have 30 minutes of time to actually do it. But thanks for the offer! [15:53] 2026-06-30T00:55:28Z #raku patrickb Where do I report bugs in Rainbow? If I use `RAKUDO_RAKUAST=1 zef install Rainbow` it fails. [15:53] 2026-06-30T01:01:38Z #raku pattrickb Don't worry, Coke showed me how to find your bugtracker. [15:53] ah that's @lizmat actually [15:54] Geth runs on my desk, indeed :-) if that's what your mean [15:54] it's also llimited in its flexibility, having hardly had any maintenance since 2017 [15:55] *** abraxxa joined [16:03] *** abraxxa left [16:04] *** abraxxa joined [16:32] *** dakkar left [17:08] *** rmv left [17:11] *** human-blip left [17:12] *** human-blip joined [17:27] I think I suggested at some point in the past that we could have a message bus of raku-related events, kind of like what the fedora project has: https://fedmsg2.readthedocs.io/en/latest/overview.html [17:27] and they have one service that handles subscriptions for end-users so they can get mails or other kinds of personal messages for specific events [17:32] there's fedmsg and fedmsg2 and i'm not sure if fedmsg2 actually describes what they've got, or if fedmsg is what they have? [17:35] https://fedora-messaging.readthedocs.io/en/stable/index.html - or this is the latest one to look at, maybe [17:41] though obviously the easiest way to have something similar without making stuff way too complicated is ... a dedicated irc channel where voiced users are bots that send events as irc messages in an official fashion [19:18] *** hurufu left [19:28] *** rmv joined [19:28] *** rmv left [19:28] *** rmv joined [19:58] *** abraxxa left [20:09] *** johnjay left [20:11] *** johnjay joined [20:26] *** xinming left [20:33] *** silug left [20:34] *** silug joined [22:21] *** Sgeo joined [23:38] *** wayland76 left [23:38] *** wayland joined [23:59] *** kst left