[00:34] *** rmv left
[00:47] *** leppard left
[01:56] *** tonyo joined
[01:59] *** hulk joined
[02:00] *** kylese left
[02:03] *** tonyo left
[02:04] *** guifa left
[02:15] *** hulk left
[02:15] *** kylese joined
[02:42] *** guifa joined
[03:09] *** guifa left
[03:22] *** lichtkind_ joined
[03:24] *** lichtkind left
[03:56] *** elcaro joined
[05:36] *** abraxxa joined
[05:45] *** abraxxa left
[05:46] *** abraxxa joined
[06:22] *** rmv joined
[06:22] *** rmv left
[06:22] *** rmv joined
[06:27] *** rmv left
[07:09] *** Sgeo left
[07:23] *** rmv joined
[07:23] *** rmv left
[07:23] *** rmv joined
[07:28] <lizmat> wayland76: could you make a PR for that change?

[07:29] <lizmat> https://codeberg.org/RakuFoundation/raku.foundation/compare/main...main

[07:46] *** dakkar joined
[08:02] *** ShimmerFairy left
[08:04] *** ShimmerFairy joined
[08:09] <disbot4> <librasteve> lets do it with class

[08:21] <disbot4> <librasteve> The upstream API https://360.zef.pm is returning content-length: 0 — the S3 bucket has an empty file looks like zef infra is still down

[08:22] <disbot4> <librasteve> I can pause the weekly until tomorrow - or skip the new/recent module section...

[08:58] <lizmat> I suggest just listing the modules that did get updates in the past week

[08:58] <lizmat> will just make next week's bigger :-)

[09:29] *** leppard joined
[09:30] *** hurufu joined
[10:01] *** tgt joined
[10:03] *** tgt left
[10:04] *** guifa joined
[10:05] <wayland76> Looks like rui beat me to it.  Thanks rui!  https://codeberg.org/RakuFoundation/raku.foundation/pulls/2 

[10:09] *** kelt0m is now known as Guest6722

[10:09] *** Guest6722 left
[10:09] *** kelt0m joined
[10:13] <wayland76> With my previous comment to guifa, I think I misread him.  Let me rescind what I said, and just say guifa++ :) 

[10:14] <guifa> Ha I 100% agree the grow the user base is consultant speak that's why I had the smiley haha

[10:15] <wayland76> It might be consultant-speak, but it's in normalish language, so I'm not against it.  It's not like leveraging synergies or whatever :) .  

[10:15] <guifa> but also agree that make people sounds strong in English (it sounds much better in other languages, so I'm guessing it's just an innocent cross language thing)

[10:16] <wayland76> Yeah, that's what I figured.  

[10:19] <lizmat> .oO( vee haz vays of making you like Raku :-)

[10:19] * wayland76 twirls moustache

[10:37] *** librasteve_ joined
[10:37] <librasteve_> notable6: weekly

[10:37] <notable6> librasteve_, 1 note: 2026-06-16T13:56:46Z <lizmat>: Sparky officially on Rocky Linux now - https://docs.rockylinux.org/10/guides/automation/sparky_getting_started/

[10:38] *** kelt0m left
[10:38] *** kelt0m joined
[10:41] <librasteve_> notable6: weekly reset

[10:41] <notable6> librasteve_, Moved existing notes to “weekly_2026-06-22T10:41:26Z”

[11:09] *** tonyo joined
[11:17] *** tonyo left
[11:40] *** kelt0m left
[11:40] *** tonyo joined
[11:41] *** wayland joined
[11:41] *** wayland76 left
[11:44] *** tonyo left
[11:48] *** rmv left
[11:52] *** rmv joined
[11:52] *** rmv left
[11:52] *** rmv joined
[12:01] <apogee_ntv> wayland / guifa: Maybe 'convince people to'? Less consultant-y, less forceful, more evangelistic/active.

[12:02] <apogee_ntv> Plz fix fez

[12:06] <wayland> apogee_ntv: I think the fez people aren't online at the moment.  I've seen the reuqest to fix it go to the right people, but they haven't responded yet.  

[12:10] <apogee_ntv> With re: foundation document I think just replacing 'user base' with 'community' would do a world of diff re-thinking it.

[12:11] <apogee_ntv> wayland: Yeah, sadly has been that way all weekend. Have been trying to publish 3 module updates.

[12:15] <wayland> Oh, that's no good.  Hopefully in a year or so we'll have a more reliable setup.  

[12:16] <apogee_ntv> Yeah I think it's just a case of setting up some kind of high availability.

[12:16] <apogee_ntv> Failover server or something

[12:17] *** tonyo joined
[12:19] <timo> .o( anycast )

[12:19] <wayland> Yeah, hasn't happened yet because of lack of funding I think.  That's one of the things the foundation is supposed to fix.  

[12:19] <apogee_ntv> Happy to help fund it :P

[12:19] <timo> it'll surely be easier to have hot standby and switch-over than it is to have multiple active instances that have to not step on each other's toes

[12:20] <apogee_ntv> If the right person can tell me what it'll cost

[12:21] <apogee_ntv> Either way should work, just need some reconciliation process somewhere that dedupes uploads so a submission is idempotent.

[12:22] *** kelt0m joined
[12:22] *** tonyo left
[12:22] <apogee_ntv> And mirroring code, and the fetch needs to check another server if a package isnt found

[12:23] <wayland> apogee_ntv: That'll probably be lizmat.  

[12:23] <apogee_ntv> Mirrored repos are a very solved problem tho

[12:26] <rmv> wayland: hope you don't mind the PR :) I'm new to the community, what's the usual process to resolve this, wait for a consensus here on IRC? On the PR? Who has the final decision?

[12:26] <wayland> As long as the raku-specific stuff doesn't cause any problems (versioning and authorship, etc).  

[12:28] *** tonyo joined
[12:32] <wayland> rmv: No, I love it -- see https://irclogs.raku.org/raku/2026-06-22.html#10:05 :) .  Great to have you already involved.  The final decision is probably the people marked as "reviewers" on the PR (though librasteve may be empowered for this also -- I'm not sure).  

[12:33] *** tonyo left
[12:33] <wayland> And I think stick with the discussion on the PR -- I think it has the best-made points and the most senior people involved in the discussion.  

[12:35] *** tonyo joined
[12:39] <wayland> Honestly, if it were me, I'd update the PR with the suggestions from librasteve (no doubt inspired by yours) and apogee taken into account.  finanalyst is probably the most senior commenter on the thread, but he doesn't seem as attached to his suggestion.  

[12:41] <[Coke]> Which PR?

[12:44] <wayland> https://codeberg.org/RakuFoundation/raku.foundation/pulls/2

[12:46] *** librasteve_ left
[12:48] *** tonyo left
[12:52] <[Coke]> ah, that's why I couldn't find one on github. :)

[12:54] <timo> github is old and busted! :D

[12:56] *** tonyo joined
[13:10] * [Coke] deletes a fork he setup on codeberg a year ago

[13:11] <apogee_ntv> Github still has actions, thats the only reason I stay there lol

[13:11] <apogee_ntv> Free multiplatform CI runs, free release artifacts

[13:12] <timo> I hope codeberg's runners are less of a train wreck than github's actions :)

[13:13] <timo> and surely we can build re-usable bits for all raku module and application maintainers that do everything they might need ... "small matter of programming", as they say :)

[13:19] <rmv> Never tried codeberg runners. Are they containers or VMs? I like https://sourcehut.org/ approach to VM runners. They stay on for a while when it fails, so you SSH and debug inside it.

[13:22] *** tonyo left
[13:24] *** justache left
[13:25] *** justache joined
[13:31] <wayland> Oh, that's cool :) .  

[13:32] <wayland> Yeah, we need to get our act together on auto-packaging.  It's on my list of things to do, but a fair way down.  

[13:34] *** tonyo joined
[13:38] *** tonyo left
[13:47] *** hurufu left
[14:00] <timo> I know there's https://felinebuildservices.org/ from whitequark, but I would expect a big "nope" if asked if rakudo could join based on the amount of AI Coding Agent Assisted Commits™

[14:01] <timo> but that's Forgejo Actions with VMs for everything instead of just linux containers, and in the future is meant to support linux, freebsd, windows, and arm64 macos. currently only linux and freebsd.

[14:02] <timo> but yet again I would like to remind everyone that https://build.opensuse.org/ exists and is not just for opensuse as the name might make you suspect

[14:04] <timo> https://build.opensuse.org/monitor - it may only be different linuces, but there's a boatload of architectures to be seen here, which is interesting in its own right

[14:13] *** abraxxa left
[14:13] *** apogee_ntv left
[14:16] *** tonyo joined
[14:16] *** abraxxa joined
[14:22] *** ShimmerFairy left
[14:22] *** ShimmerFairy joined
[14:54] *** Pixi` joined
[14:55] *** Pixi left
[14:56] *** xybre joined
[14:57] <xybre> \o

[15:05] <disbot4> <librasteve> hi

[15:07] <disbot4> <librasteve> currently raku.foundation lives in codeberg, but CI remains on the github mirror … kudos to anyone who can supply codeberg CI (I have seen woodpecker mentioned … but that needs you to bring your own machine, right?)

[15:08] <disbot4> <librasteve> it’s about as simple as CI can get - build an image from Dockerfile and upload to quay.io

[15:11] <xybre> I was looking at Raku's gradual type syntax, and I was trying to find more info about the way that square and curly braces are used, in like hashmap type definitions: `Hash[Num,Int]` vs `Num %foo3{Int}`. What does Raku call these? I would like to read more in the docs

[15:18] <timo> the syntax with [] is for giving roles values to their parameters; the syntax with {} is for adding a type to the key of a hash variable

[15:18] <timo> putting a `my %foo` is implicitly giving a type of Associative with its default role arguments to the %foo variable

[15:21] <timo> and as you saw putting the type before the % puts it in one slot while putting it in the { } after the variable name puts it in the other

[15:26] <xybre> Okay so the {} syntax is one-off, specific to hashes and isn't used for other things?

[15:27] <xybre> I did see the Roles page, I wasn't sure if it was the same thing, good to know

[15:27] <timo> m: my @foo{Int}; # reserved for future use

[15:27] <camelia> rakudo-moar 66b4e5351: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤The {} shape syntax with the @ sigil is reserved␤at <tmp>:1␤------> my @foo{Int<HERE>}; # reserved for future use␤    expecting any of:␤        statement end␤        statement modifier␤        sta…»

[15:33] <xybre> Gotcha, thanks!

[15:34] *** abraxxa left
[15:36] *** tonyo left
[15:37] *** Pixi` is now known as Pixi

[15:39] *** tonyo joined
[15:42] *** librasteve_ joined
[15:42] *** abraxxa joined
[15:46] *** abraxxa left
[15:46] *** abraxxa1 joined
[15:47] *** abraxxa1 left
[15:48] <timo> no problem! :)

[15:49] *** tonyo left
[15:50] <timo> @librasteve, just thought I'd mention: `my constant` is actually BEGIN time, not INIT time; INIT is after compilation has finished and happens early at run time of the program (so critically, it should run every time you start the program anew)

[15:51] <lizmat> true, but the current behaviour of @-sigilled constants *is* in many cases currently equivalent to INIT time :-(

[15:52] <timo> I wouldn't say that either; INIT time stuff runs only once per block you put INIT on :P

[15:53] <timo> the issue we saw is that you're compile-time constructing a lazy list and well, whoever gets values from it will iterate the iterator and fill the iteration target and if multiple threads work on it at the same time, kaboom

[15:53] <timo> which is contrary to what you would expect from something that is "my constant @xyz"

[15:54] *** tonyo joined
[15:54] <timo> as you pointed out, that doesn't feel very "constant", and it's not really obvious to users that "constant" in rakudo kind of just means "compile time evaluated and serialized into the precompilation result"

[15:55] <lizmat> well, as I said, I would argue that it is a bug, and that @-sigilled constants should have an "eager" in their evaluation

[15:57] <timo> yup

[15:59] <disbot4> <librasteve> I agree that [my] constant @a = 1,2,3 should be [implicitly] eager based on my understanding and it helps clarify to me that constant is evaluated at BEGIN time - thank you

[16:00] *** tonyo left
[16:00] <disbot4> <librasteve> actually that code is in Cro::WebApp::Form - so I am not the author - don't shoot the maintainer!

[16:01] <timo> no shooting intended

[16:05] <disbot4> <librasteve> no worries - my understanding is that "compile time constructing a lazy list" means the compiler is making an Iterable object? and the first thread to access @a gets to reify it via the assignment which may not be finishe when thread #2 arrives - is that roughly correct?

[16:05] *** tonyo joined
[16:07] <timo> that's roughly correct, but saying "the assignment" might oversimplify the internals a little bit? i guess it depends on how deep you need to dive to answer any specific question so can't really say in general if it's correct enough :)

[16:09] <timo> one of the errors, "no such method something-something-something for object of repr VMNull", was caused by one thread nulling out the "reifier" attribute of the lazy list in the exact moment between another thread checking if there is a value in the reifier attribute, and taking the value and calling a method on it.

[16:11] *** tonyo left
[16:14] *** tonyo joined
[16:35] <librasteve_> https://rakudoweekly.blog/2026/06/22/2026-25-dutch-art/

[16:40] <timo> librasteve_: in the heading "Why Sparky and Sparrow for Rocky Linux testing?¶" can you toss out the paragraph symbol? that probably got copied by accident

[16:42] <tonyo> .

[16:42] <tellable6> 2026-06-07T14:24:49Z #raku-dev <guifa> tonyo: eastern

[16:42] <tellable6> 2026-06-20T10:29:51Z #raku <lizmat> tonyo looks like fez is having issues

[16:43] *** dakkar left
[16:47] *** tonyo left
[16:53] *** Geth joined
[17:09] *** tonyo joined
[17:09] <tonyo> fez should be back up

[17:11] <lizmat> tonyo++

[17:11] <timo> thank you tonyo :)

[17:11] <tonyo> not sure what is happening with it all of a sudden, it starts paging and then i can't get in to do any diagnostics

[17:15] * lizmat just successfully uploaded a new module

[17:34] <timo> what kind of system is that? there's some things you can do on linux with cgroups and such to get earlier kills instead of endless paging and swap death spiral

[17:35] <timo> do you happen to have `sar` installed? it might give you some measurements from near the time it exploded

[17:38] <timo> tonyo: something that can relatively reliably get the system to page itself to death is having a tmpfs and putting infinitely growing data in it. for example if your /tmp is a tmpfs

[17:38] <tonyo> crap.

[17:38] *** wayland left
[17:40] *** wayland joined
[17:40] <timo> I have to go AFK for maybe like an hour, but feel free to hit me up if you need advice on this or want to give me a root shell or something ;)

[17:40] <tonyo> we're discussing in the infra about migrating to raku infra

[17:40] <tonyo> i think it's a fairly easy/straight forward migration

[17:40] <timo> oh my irc box recently restarted so I'm no longer in there

[18:07] *** enyc left
[18:07] *** sjn left
[18:08] *** sjn joined
[18:36] *** librasteve_ left
[18:41] *** belluzj joined
[18:43] *** vrurg_ joined
[18:44] *** vrurg left
[19:34] *** guifa left
[19:36] <disbot4> <librasteve> tonyo++

[19:38] *** librasteve_ joined
[19:41] <librasteve_> timo: I am working on the assumption that the constant @ eager fix will be in 2026.06 - is that realistic, or do we need to patch Cro::WebApp::Form?

[19:44] <librasteve_> weekly para symbol cut btw

[19:50] <timo> I'm personally not working on implementing that, maybe liz is. it feels like it can be written in not too much time, but would want not just a spectest run but perhaps also a blin run to see if it makes a difference to any ecosystem modules

[19:53] <ugexe> why not just patch cro::webapp::form so users of recent but not the very latest rakudo can still use your module? does not rewriting that line bring that much value to it for that trade off?

[19:54] <timo> I'm not sure. maybe librasteve_ doesn't have push access?

[19:55] <timo> and/or can't publish it to the ecosystem

[19:57] <ugexe> librasteve_: fyi with 3 of the open PRs to rakudo merged I think Cro::WebApp will install under RAKUDO_RAKUAST=1

[19:58] <ugexe> ugexe/return-check-signature-lexical, ugexe/rakuast-typeobject-attr-default, and ugexe/rakuast-begin-time-regex-arg (+ whatever is already on HEAD)

[20:00] *** belluzj left
[20:03] *** belluzj joined
[20:05] <disbot4> <librasteve> no worries, I will patch and release Cro::WebApp::Form with the eager version shortly (just want to be sure it is not wasted effort and patching a non existent issue ;-) )

[20:09] <ugexe> i might have missed something, but has whatever buggy behavior you are mentioning been released already?

[20:16] <lizmat> librasteve putting eager in front is a workaround that will continue to work

[20:16] <lizmat> even if  we fixed this

[20:17] <disbot4> <librasteve> it's a rakudo/moarvm bug that came to light from the raku.foundation logs after we had four or five 500 errors on Thursday? morning - a time of peak traffic directly on a Cro::WebApp::Form item on the homepage - since it's a non-deterministic race condition my guess is that this is the first time that this code combination has been under load (the debugging and root cause determination is set out here

[20:17] <disbot4> https://github.com/Raku/infra/issues/122)

[20:18] <lizmat> ugexe: basically, @a-sigilled constants may not be constant

[20:18] <lizmat> the most extreme case:

[20:18] <lizmat> m: my constant @a = 1 .. Inf

[20:18] <camelia> rakudo-moar 66b4e5351: ( no output )

[20:18] <disbot4> <librasteve> yeah, sure - it's just a faff to patch and release part of Cro and a lazy coder like me prefers to fix the problem once ;-)

[20:19] <lizmat> a less extreme example is:

[20:19] <ugexe> i see. but what i was getting as was if this has always been the case then there is value in librasteve fixing that module to work with this always-broken (as well as the future fixed) behavior

[20:19] <disbot4> <librasteve> oh, yeah probably better that Cro::WebApp works with older raku's - good point

[20:19] <lizmat> the problem is that a constant List can be frozen with an empty $!reified and an valid $!todo

[20:20] <disbot4> <librasteve> anyway I accept the task

[20:20] <ugexe> librasteve++

[20:21] <lizmat> and if multiple threads start reifying, one of them can decide: hey, there's something to reify, and then hit a VMnull because another thread just reified and reset $!todo

[20:23] <lizmat> I actually need to check all of my modules for this as well  :-(

[20:28] <ugexe> lizmat: there is nothing wrong with testing internal methods in the rakudo test suite

[20:28] <ugexe> it isnt the same as the spec test suite

[20:28] <lizmat> well, that method doesn't exist anymore

[20:29] <ugexe> i dont disagree with removing it, only for one of the reasons you stated

[20:29] <lizmat> ok, fair enough, but it just felt as a wrong test to start with...  

[20:31] <ugexe> it was a test that literally proved the change in the commit it came with worked as stated. i'm not sure what else you would want from a test :)

[20:32] <ugexe> im not agreeing it wasnt a great test. its more to show whoever (if anyone) reviewed the code that it does what it says

[20:32] <lizmat> well, true, but the point of the fix was to fix an issue with smart-matching.   the way it got fixed, shouldn't really matter

[20:33] <ugexe> good point

[20:34] *** mehbark left
[20:36] *** mehbark joined
[20:43] *** itaipu joined
[20:51] *** belluzj left
[21:42] <disbot4> <aruniecrisps> i wanted to share this with you guys and see whether there were some gems in here you might find interesting: https://docs.racket-lang.org/rhombus/index.html

[21:42] <disbot4> <aruniecrisps> sort of reminded my of codesection's Raku's really good Lisp impression article

[21:43] <disbot4> <aruniecrisps> Raku's approach with Slangs is quite similar to the Racket ecosystem of languages

[22:04] *** Sgeo joined
[22:22] *** guifa joined
[22:32] *** apogee_ntv joined
[23:07] <wayland> timo: On the topic of build packaging, my goal was more along the lines of "define build config once, then it will generate for every build system (ie. RPM, deb, apk, docker, etc).  Your idea is definitely interesting though.  

[23:16] <wayland> aruniecrisps: That's an index to a whole lot of documentation.  Were you wanting to recommend any page in particular?  

[23:44] *** guifa left