🦋 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:07 reportable6 left 00:08 reportable6 joined 00:46 bloatable6 joined, releasable6 joined 00:47 bisectable6 joined, coverable6 joined, linkable6 joined 00:48 committable6 joined, shareable6 joined 01:25 vrurg_ joined 01:27 vrurg left 01:44 frost joined 01:45 ugexe left 01:46 tellable6 joined 02:08 ugexe joined 02:10 ugexe left 02:11 ugexe joined 02:46 greppable6 joined 03:07 Xliff_ left 03:47 statisfiable6 joined, benchable6 joined
Xliff m: {LEAVE say 'A'; {LEAVE say 'B'; { LEAVE say"C"; { LEAVE say "D"; die "Bleah!" } } } } 04:47
camelia ===SORRY!===
Argument to "say" seems to be malformed
at <tmp>:1
------> AVE say 'A'; {LEAVE say 'B'; { LEAVE say⏏"C"; { LEAVE say "D"; die "Bleah!" } } }
Two terms in a row
at <tmp>:1
------> AVE say 'A'; {LEAVE say 'B'; {…
Xliff m: {LEAVE say 'A'; {LEAVE say 'B'; { LEAVE say "C"; { LEAVE say "D"; die "Bleah!" } } } }
camelia D
in block at <tmp> line 1
in block at <tmp> line 1
in block <unit> at <tmp> line 1

04:47 evalable6 left, linkable6 left
moon-child I think there's an issue for that 04:48
Xliff Welll... behaves as I'd hoped.
D C B A are printed. 04:49
I'm surprised "D" was printed before the exception, though.
moon-child oh, I missed that. Thought C B A weren't printed at all 04:50
Well, at any rate I think there is a similar form which behaves unexpectedly and for which there is an issue :P
Xliff :> -- Thanks for mentioning it! 04:56
04:58 Xliff_ joined
Voldenet …exception should be on the end though, right? 05:00
m: CATCH { default { say $_.message; }}; { LEAVE say "A"; { LEAVE say "B"; { LEAVE say "C"; { LEAVE say "D"; die "Bleah!" } } } } 05:03
camelia Bleah!
Voldenet m: CATCH { default { say $_.message; .resume }}; { LEAVE say "D"; { LEAVE say "C"; { LEAVE say "B"; { LEAVE say "A"; die "Bleah!" } } } }; say "E"; 05:04
camelia Bleah!
Voldenet it kind of makes sense
06:04 releasable6 left, benchable6 left, greppable6 left, statisfiable6 left, shareable6 left, bloatable6 left, unicodable6 left, reportable6 left, notable6 left, nativecallable6 left, coverable6 left, committable6 left, sourceable6 left, squashable6 left, bisectable6 left, quotable6 left 06:05 bloatable6 joined, committable6 joined, benchable6 joined, squashable6 joined, nativecallable6 joined 06:06 sourceable6 joined, bisectable6 joined, reportable6 joined, quotable6 joined, coverable6 joined 06:07 shareable6 joined, notable6 joined, releasable6 joined 07:05 statisfiable6 joined 07:08 unicodable6 joined 07:49 evalable6 joined 09:06 greppable6 joined
Geth rakudo/fix_concurrent_module_loading: 835d0f12a9 | (Stefan Seifert)++ | 2 files
Fix segfaults due to concurrent hash access in parallel module loading

Read access to the %!seen and %!loaded hashes in CompUnit::Repository:: Installation and FileSystem was not protected by a lock. This could lead to us fetching an only half-setup entry from the hash with a key that was still a NULL pointer which we then dereferenced.
Fix by extending (or introducing) locks to all access to those hashes.
rakudo: niner++ created pull request #4679:
Fix segfaults due to concurrent hash access in parallel module loading
09:17 frost left 09:18 frost joined 09:49 linkable6 joined 11:34 Altai-man joined 11:36 Xliff_ left 12:04 squashable6 left 12:06 squashable6 joined 12:08 reportable6 left 12:10 reportable6 joined
ugexe heh i wrote that ^ same code at one point investigating github.com/rakudo/rakudo/issues/1920 but when it didnt help in that instance i never did anything further with it 12:43
13:31 [Coke] left 13:34 [Coke] joined 14:11 frost left
lizmat notable6: weekly 16:58
notable6 lizmat, No notes for “weekly”
17:21 evalable6 left, linkable6 left 18:07 reportable6 left 18:09 reportable6 joined 18:15 Altai-man left 18:21 linkable6 joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/12/20/2021-...ransiting/ 18:59
19:22 atroxaper joined
atroxaper Hello, #raku 19:35
Do we still in search of the new release master? I have a desire to do releases. I've research rakudo/docs/release_* files. Please, tell me what are the obstacles to this? I do not have a much powerful machine (but have all three os) and have poor English :) You can simply say 'not you, not now'.
lizmat jdv has volunteered for the 2021.12 release 19:36
but has some sad IRL issues to deal with atm 19:37
atroxaper lizmat: thumb. Good luck to jdv then. 19:38
lizmat atroxaper: but that doesn't mean you wouldn't be able to do the 2022.01 one ? 19:39
it's our intent to get more people to do releases to reduce the chance of burnout
atroxaper I I'm happy to sit on the waiting list. If you will need me.
lizmat will keep it in mind! :-) thanks for offering! 19:41
atroxaper Thank you.
jdv i'm around, kinda 19:43
i posted changelogs for moarvm and rakudo so far but that's as far as i've got today 19:44
atroxaper jdv++ 19:45
nine jdv: FWIW I'm pretty sure I've fixed (e.g. created PRs) for all regressions affecting LibXML and thus all regressions caused by my work. The remaining stability issues with 90-threads.t are probably longstanding issues. 19:52
jdv i noticed that, thanks. any idea when those'll be merged? 20:00
nine: ^ 20:01
it appears the moarvm PR failed some build stuff? 20:04
lizmat nine jdv I could merge them / bump now
nine jdv: that's a false positive. t/02-rakudo/15-gh_1202.t is known to give trouble. There is at least the expr JIT race condition still causing the occasional failure. 20:13
lizmat: I was hoping jnthn++ would find some time for a review 20:15
jdv nine: cool, thanks
lizmat well, let me know when I need to start bumping :-)
jdv i guess there's no way around that. that's probably a hard block on release, right? 20:16
lizmat nine ^^ ? 20:20
20:20 patrickb joined, atroxaper left
nine I wouldn't release without those fixes. But I wouldn't wait forever for reviews either 20:21
20:21 evalable6 joined
jdv i'm in no hurry. i'll wait a few days and then squawk again i guess. 20:22
nine Anyway there are still other unfixed regressions in the latest Blin run, aren't there? 20:24
jdv no, all are accounted for 20:25
the other 3 i just filed issues on the dists for
they were all just fallout from the ro fixes from codesections
20:33 japhb left
nine And we are sure the fixes warrant breaking backwards compatibility? 20:35
jdv i'm not *sure* about that. the breakage looked simple to fix. what's the alternative? we kick the can down the road to next month? 20:42
nine We could make the fix depend on language version. Whether that's the best course of action depends on what we gain by fixing the bug. Unfortunately the commit message doesn't tell this, just that it wasn't supposed to work but did anyway. 20:52
Breaking existing code just for purity seems a bit harsh. If we gain e.g. important optimizations by doing so, it could still be worth it 20:53
21:09 MasterDuke left 21:21 MasterDuke joined
jdv i agree but i assumed it was "good to go" since the PR was reviewed and had comments and such. 21:47
nine At the time of the PR we didn't know that there would be actual ecosystem regressions caused by it 21:54
jdv on a random tangent i'm bewildered at the comment on the pr "+1 from me provided roast isn't being changed."... 22:02
nine To be clear: I have no strong opinion on whether to revert, require to make this language version dependant or just accept the fallout. My aim in bringing this up was just so we do not blindly move on but be aware of the options. 22:07
jdv nine: ok 22:09
codesections: we need to talk
Geth Die/main: 12 commits pushed by (Zoffix Znet)++, (Elizabeth Mattijsen)++
review: github.com/raku-community-modules/...ca8f88ee98
22:46 patrickb left
Geth Die/main: e69499193d | (Elizabeth Mattijsen)++ | 11 files
Die/main: d736d107b6 | (Elizabeth Mattijsen)++ | 2 files
Fix pod nit
tonyo which issue is this? what's the ecosystem regression? jdv nine ? 23:43
lizmat calls it a day 23:44