🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth rakudo: f83e551163 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Buf.pm6
Add .Buf / .Blob coercers to Blob / Buf (#4374)

Add .Buf / .Blob coercers to Blob / Buf
This is a bit of a special case, as Buf / Blob are both *roles*, yet they are generally used as classes with their default parameterization.
... (10 more lines)
10:48
lizmat notable6: weekly 11:24
notable6 lizmat, 2 notes: 2021-05-25T09:08:23Z <El_Che>: new rakudo-pkg 2021.05 ; 2021-05-30T09:18:25Z <El_Che>: m.slashdot.org/story/386026
lizmat notable6: weekly reset 11:25
notable6 lizmat, Moved existing notes to “weekly_2021-05-31T11:25:24Z”
Geth rakudo/pick-hyperwhatever: bb057bc890 | (Elizabeth Mattijsen)++ | src/core.c/List.pm6
RFC for a .pick(**) candidate

Like .pick(*), this would exhaust all possible values. But instead of stopping providing values, continues with a fresh set again.
The advantage over just using .roll(*) is that you're guaranteed a more even distribution of values on shorter runs exceeding the original pool size.
12:26
rakudo: lizmat++ created pull request #4385:
RFC for a .pick(**) candidate
12:27
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/05/31/2021-...r-the-bus/ 14:38
japhb lizmat: There are some games that want exactly the behavior you're talking about in your RFC. Modern Tetris variants, for example, guarantee that you'll cycle through the different shapes (in random order each time, but always completing a set before going to the next) 16:49
lizmat japhb: the reason I was suggesting it was cycling through colors for colorizing nicks in IRC logs :-) 19:15
moon-child hmm, I feel like in that case you would want it to be weighted 19:26
so if a new person joins, their colour is different from the colours of the people who are currently acativ
or hell maybe you even do graph partitioning to try to reduce overlap. I am definitely overengineering this :P
lizmat moon-child: well, I'd also like the coloring of nicks to be consistent for all of the days on the channel :-) 19:31
but for a certain design and background, you would need to exclude a lot of colors because of lack of contrast 19:32
moon-child right, but in the event that someone who's never been in the channel before joins, wouldn't you want to make their colour contrast with those of the people that are actually talking, rather than contrasting with all of the people who have ever been in the channel? 19:33
lizmat I'm more worried about the contrast with the design, then the contrast difference between nocks 19:43
*nicks
you would seldom see those nicks close enough to not make a difference :-) 19:44
[TuxCM] Rakudo v2021.05-3-gf83e55116 (v6.d) on MoarVM 2021.05-12-g4751ca6da
csv-ip5xs0.885 - 0.931
csv-ip5xs-208.674 - 9.153
csv-parser27.058 - 27.424
csv-test-xs-200.370 - 0.430
test7.400 - 7.704
test-t2.104 - 2.158
test-t --race0.934 - 0.964
test-t-2035.470 - 36.135
test-t-20 --race9.623 - 9.976
20:19
moon-child fair enough 20:32