šŸ¦‹ 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.
00:05 [Coke] joined 01:43 hankache joined 01:52 hankache left 04:33 unicodable6 left, evalable6 left, releasable6 left, benchable6 left, quotable6 left, notable6 left, bloatable6 left, squashable6 left, shareable6 left, greppable6 left, nativecallable6 left, coverable6 left, bisectable6 left, statisfiable6 left, sourceable6 left, committable6 left
Xliff p6-GLib-Suite compile times: 05:40
Total non-parallel compile times: 9164.94s
Total parallel compile times: 1644.62896181s
The regression from last week looks to be resolved. Thank you, lizmat! 05:41
05:59 Xliff left
lizmat Thank you, Xliff, but I don't think I did anything to fix that 06:42
Geth whateverable: fd87ed7145 | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Whateverable/Discordable.pm6
Fix the list of discord bridge bot names

The bot was renamed a long time ago, so the list needs to be changed accordingly. All whateverable bots understand commands sent through the bridge, but only if they know the nickname of the bot that implements the bridge.
06:44
whateverable: 2bd990d275 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/Whateverable/Discordable.pm6
Merge pull request #385 from AlexDaniel/fix-discord-bot-name

Fix the list of discord bridge bot names
lizmat Files=1352, Tests=117129, 299 wallclock secs (36.27 usr 9.84 sys + 4111.11 cusr 331.89 csys = 4489.11 CPU) 06:58
07:19 CIAvash left, AlexDaniel left, uzl[m] left, MitarashiDango[m left, crystalfrost[m] left 07:24 AlexDaniel joined 07:33 uzl[m] joined, CIAvash joined, crystalfrost[m] joined, MitarashiDango[m joined 07:40 hankache joined, hankache left
Geth rakudo: ec20a3f010 | (Elizabeth Mattijsen)++ | src/core.c/stubs.pm6
Make &DYNAMIC take a native str

Because that now makes it slightly better optimizable and produces smaller bytecode (390 -> 374). Sadly, it won't inline because of the nqp::getlexdyns. It used to not inline because it was too big.
08:23
08:46 MasterDuke left 08:52 sena_kun left 08:53 sena_kun joined
Geth rakudo: 173a75b07e | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/EXPORTHOW.nqp
Speedup / fix race condition on EXPORTHOW

Reduce the number of nqp::how calls, and put a lock around it to make sure it isn't a race condition on changing the underlying hash.
For some reason, this gets called on *every* Raku startup. One would sorta expect this to be compile time somehow.
08:56
rakudo: 34d2816426 | (Elizabeth Mattijsen)++ | 3 files
Change name of ContainerDescriptor::BindHashPos to ..Key

This container descriptor logic applies to hashes, and with hashes we refer to "keys" rather than to "positions". Probably a copy-pasto.
09:10
10:07 sena_kun left 10:08 sena_kun joined 11:05 uzl[m] left, AlexDaniel left, CIAvash left, crystalfrost[m] left 11:07 MitarashiDango[m left
lizmat notable6: weekly 12:48
12:49 AlexDaniel joined
nine lizmat: I do see why that EXPORTHOW code runs on every startup: it's just part of the setting's mainline 12:57
12:57 CIAvash joined, uzl[m] joined, crystalfrost[m] joined, MitarashiDango[m joined
lizmat ok, so then there wouldn't be an issue with putting the initializing in a BEGIN block 12:59
13:06 Xliff joined
Xliff lizmat: I see your change where you attempt to precompile in dependency order. 13:06
Why not asssume META6.json is in that order and then make tools to minimize the work needed for that to happen? 13:07
lizmat because the META6.json<provides> is a hash without inherent order 13:08
Xliff Oh, crap.
I keep forgetting that.
Well, I do have this: [8:41 AM] Lakeena Bruno
Good Morning. Please have Joe contact the PM to request contract project codes. Ā Thank you
Fahrfignugen. Wrong paste.
lizmat hehe
Xliff github.com/Xliff/p6-GtkPlus/blob/m...encies.pl6 # right link
Would it be helpful to have provides either specified as a list of pairs or a hash? 13:09
If given as a list of Pairs, then you can assume dependency order?
lizmat yes... but we need to distinguish two cases, really:
initial compilation, and re-compilation after a setting update 13:10
in the latter case, we *know* the dependencies
Xliff A provides using "[]" instead of "{}" would work in both cases, neh? 13:12
lizmat Xliff: in any case, I've been doing a lot of testing out of ideas in the past days, and will come back with some a problem solving issue most likely 13:13
Xliff OK. Works for me!
lizmat which should describe a path in which testing and installing would only require precompilation once
Xliff Oh. That makes me so happy.
lizmat the only tricky bit is really getting rid of "use lib" in test-files 13:14
13:28 hankache joined 13:32 hankache left 14:56 ggoebel left 15:00 ggoebel joined 16:08 MasterDuke joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/03/28/2022-...admapping/ 16:53
17:28 sena_kun left 17:29 sena_kun joined 17:51 sena_kun left
sjn lizmat++ #RWN 17:51
17:52 sena_kun joined 18:33 hankache joined 18:53 hankache left 23:19 Xliff left