[00:07] *** reportable6 left [00:08] *** reportable6 joined [00:46] *** bloatable6 joined [00:46] *** releasable6 joined [00:47] *** bisectable6 joined [00:47] *** coverable6 joined [00:47] *** linkable6 joined [00:48] *** committable6 joined [00:48] *** 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 [03:47] *** benchable6 joined [04:47] m: {LEAVE say 'A'; {LEAVE say 'B'; { LEAVE say"C"; { LEAVE say "D"; die "Bleah!" } } } } [04:47] rakudo-moar b5fb3628b: OUTPUT: «===SORRY!===␤Argument to "say" seems to be malformed␤at :1␤------> AVE say 'A'; {LEAVE say 'B'; { LEAVE say⏏"C"; { LEAVE say "D"; die "Bleah!" } } }␤Two terms in a row␤at :1␤------> AVE say 'A'; {LEAVE say 'B'; {…» [04:47] m: {LEAVE say 'A'; {LEAVE say 'B'; { LEAVE say "C"; { LEAVE say "D"; die "Bleah!" } } } } [04:47] rakudo-moar b5fb3628b: OUTPUT: «D␤Bleah!␤ in block at line 1␤ in block at line 1␤ in block at line 1␤␤C␤B␤A␤» [04:47] *** evalable6 left [04:47] *** linkable6 left [04:48] I think there's an issue for that [04:48] Welll... behaves as I'd hoped. [04:49] D C B A are printed. [04:49] I'm surprised "D" was printed before the exception, though. [04:50] 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 [04:56] :> -- Thanks for mentioning it! [04:58] *** Xliff_ joined [05:00] …exception should be on the end though, right? [05:03] m: CATCH { default { say $_.message; }}; { LEAVE say "A"; { LEAVE say "B"; { LEAVE say "C"; { LEAVE say "D"; die "Bleah!" } } } } [05:03] rakudo-moar b5fb3628b: OUTPUT: «Bleah!␤D␤C␤B␤A␤» [05:04] m: CATCH { default { say $_.message; .resume }}; { LEAVE say "D"; { LEAVE say "C"; { LEAVE say "B"; { LEAVE say "A"; die "Bleah!" } } } }; say "E"; [05:04] rakudo-moar b5fb3628b: OUTPUT: «Bleah!␤A␤B␤C␤D␤E␤» [05:04] it kind of makes sense [06:04] *** releasable6 left [06:04] *** benchable6 left [06:04] *** greppable6 left [06:04] *** statisfiable6 left [06:04] *** shareable6 left [06:04] *** bloatable6 left [06:04] *** unicodable6 left [06:04] *** reportable6 left [06:04] *** notable6 left [06:04] *** nativecallable6 left [06:04] *** coverable6 left [06:04] *** committable6 left [06:04] *** sourceable6 left [06:04] *** squashable6 left [06:04] *** bisectable6 left [06:04] *** quotable6 left [06:05] *** bloatable6 joined [06:05] *** committable6 joined [06:05] *** benchable6 joined [06:05] *** squashable6 joined [06:05] *** nativecallable6 joined [06:06] *** sourceable6 joined [06:06] *** bisectable6 joined [06:06] *** reportable6 joined [06:06] *** quotable6 joined [06:06] *** coverable6 joined [06:07] *** shareable6 joined [06:07] *** notable6 joined [06:07] *** releasable6 joined [07:05] *** statisfiable6 joined [07:08] *** unicodable6 joined [07:49] *** evalable6 joined [09:06] *** greppable6 joined [09:07] ¦ rakudo/fix_concurrent_module_loading: 835d0f12a9 | (Stefan Seifert)++ | 2 files [09:07] ¦ rakudo/fix_concurrent_module_loading: Fix segfaults due to concurrent hash access in parallel module loading [09:07] ¦ rakudo/fix_concurrent_module_loading: [09:07] ¦ rakudo/fix_concurrent_module_loading: Read access to the %!seen and %!loaded hashes in CompUnit::Repository:: [09:07] ¦ rakudo/fix_concurrent_module_loading: Installation and FileSystem was not protected by a lock. This could lead to us [09:07] ¦ rakudo/fix_concurrent_module_loading: fetching an only half-setup entry from the hash with a key that was still a [09:07] ¦ rakudo/fix_concurrent_module_loading: NULL pointer which we then dereferenced. [09:07] ¦ rakudo/fix_concurrent_module_loading: [09:07] ¦ rakudo/fix_concurrent_module_loading: Fix by extending (or introducing) locks to all access to those hashes. [09:07] ¦ rakudo/fix_concurrent_module_loading: review: https://github.com/rakudo/rakudo/commit/835d0f12a9 [09:07] ¦ rakudo: niner++ created pull request #4679: Fix segfaults due to concurrent hash access in parallel module loading [09:07] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/4679 [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 [12:43] heh i wrote that ^ same code at one point investigating https://github.com/rakudo/rakudo/issues/1920 but when it didnt help in that instance i never did anything further with it [13:31] *** [Coke] left [13:34] *** [Coke] joined [14:11] *** frost left [16:58] notable6: weekly [16:58] lizmat, No notes for “weekly” [17:21] *** evalable6 left [17:21] *** linkable6 left [18:07] *** reportable6 left [18:09] *** reportable6 joined [18:15] *** Altai-man left [18:21] *** linkable6 joined [18:59] and yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2021/12/20/2021-51-transiting/ [19:22] *** atroxaper joined [19:35] 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'. [19:36] jdv has volunteered for the 2021.12 release [19:37] but has some sad IRL issues to deal with atm [19:38] lizmat: thumb. Good luck to jdv then. [19:39] 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 [19:39] I I'm happy to sit on the waiting list. If you will need me. [19:41] will keep it in mind! :-) thanks for offering! [19:41] Thank you. [19:43] i'm around, kinda [19:44] i posted changelogs for moarvm and rakudo so far but that's as far as i've got today [19:45] jdv++ [19:52] 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. [20:00] i noticed that, thanks. any idea when those'll be merged? [20:01] nine: ^ [20:04] it appears the moarvm PR failed some build stuff? [20:04] nine jdv I could merge them / bump now [20:13] 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:15] lizmat: I was hoping jnthn++ would find some time for a review [20:15] nine: cool, thanks [20:15] well, let me know when I need to start bumping :-) [20:16] i guess there's no way around that. that's probably a hard block on release, right? [20:20] nine ^^ ? [20:20] *** patrickb joined [20:20] *** atroxaper left [20:21] I wouldn't release without those fixes. But I wouldn't wait forever for reviews either [20:21] *** evalable6 joined [20:22] i'm in no hurry. i'll wait a few days and then squawk again i guess. [20:24] Anyway there are still other unfixed regressions in the latest Blin run, aren't there? [20:25] no, all are accounted for [20:25] the other 3 i just filed issues on the dists for [20:25] they were all just fallout from the ro fixes from codesections [20:33] *** japhb left [20:35] And we are sure the fixes warrant breaking backwards compatibility? [20:42] 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:52] 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:53] 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 [21:09] *** MasterDuke left [21:21] *** MasterDuke joined [21:47] i agree but i assumed it was "good to go" since the PR was reviewed and had comments and such. [21:54] At the time of the PR we didn't know that there would be actual ecosystem regressions caused by it [22:02] on a random tangent i'm bewildered at the comment on the pr "+1 from me provided roast isn't being changed."... [22:07] 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:09] nine: ok [22:09] codesections: we need to talk [22:44] ¦ Die/main: 12 commits pushed by (Zoffix Znet)++, (Elizabeth Mattijsen)++ [22:44] ¦ Die/main: review: https://github.com/raku-community-modules/Die/compare/f8f63eed384d^...a8ca8f88ee98 [22:46] *** patrickb left [22:53] ¦ Die/main: e69499193d | (Elizabeth Mattijsen)++ | 11 files [22:53] ¦ Die/main: 1.1 [22:53] ¦ Die/main: review: https://github.com/raku-community-modules/Die/commit/e69499193d [23:41] ¦ Die/main: d736d107b6 | (Elizabeth Mattijsen)++ | 2 files [23:41] ¦ Die/main: Fix pod nit [23:41] ¦ Die/main: review: https://github.com/raku-community-modules/Die/commit/d736d107b6 [23:43] which issue is this? what's the ecosystem regression? jdv nine ? [23:44] * lizmat calls it a day