|
🦋 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
|
|||