[00:35] ¦ rakudo: Xliff++ created pull request #4113: Displays default values for parameters in sub MAIN [00:35] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/4113 [00:43] *** stoned75 left [00:45] *** stoned75 joined [01:49] *** stoned75 left [02:05] *** lucasb left [03:36] *** rypervenche left [03:40] *** rypervenche joined [04:02] *** leont left [04:04] ¦ rakudo: vrurg++ created pull request #4114: Do all coercion type makeup within parametrization [04:04] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/4114 [04:52] *** Xliff left [06:20] *** frost-lab joined [06:44] *** stoned75 joined [06:50] *** stoned75 left [08:03] *** stoned75 joined [08:08] *** sena_kun joined [08:17] *** domidumont joined [09:08] *** Altai-man joined [09:11] *** frost-lab left [09:11] *** sena_kun left [10:07] *** morayj joined [10:16] *** morayj_ joined [10:17] *** morayj left [10:17] *** morayj_ is now known as morayj [10:43] *** MasterDuke left [11:00] ¦ rakudo: lizmat self-assigned successive 'use' statements in the REPL error out with 'undeclared routine' https://github.com/rakudo/rakudo/issues/4115 [11:03] *** MasterDuke joined [12:15] *** [TuxCM] is now known as [Tux] [13:09] *** sena_kun joined [13:11] *** Altai-man left [13:19] *** leont joined [13:20] *** squashable6 left [13:21] *** squashable6 joined [13:43] *** [TuxCM] joined [13:49] *** [TuxCM] left [14:18] ¦ rakudo: b5465b1769 | (Vadim Belman)++ | 2 files [14:18] ¦ rakudo: Do all coercion type makeup within parametrization [14:18] ¦ rakudo: [14:18] ¦ rakudo: Don't use compose. This would also serve as a bit of optimization by [14:18] ¦ rakudo: reducing number of calls needed to create a coercion type. [14:18] ¦ rakudo: [14:18] ¦ rakudo: Alongside got rid of accessing attributes via accessors and replaced [14:18] ¦ rakudo: with direct references. This would also remove extra method invocations. [14:18] ¦ rakudo: [14:18] ¦ rakudo: Should fix Net::BGP, as bisected in #4108 [14:19] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/b5465b1769 [14:19] RAKUDO#4108 [open]: https://github.com/rakudo/rakudo/issues/4108 [BLOCKER][blin][regression] Blin 2020.12, round 3 [14:19] ¦ rakudo: e481619843 | (Vadim Belman)++ | src/Perl6/Metamodel/CoercionHOW.nqp [14:19] ¦ rakudo: Remove a overlooked call to compose [14:19] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/e481619843 [14:19] ¦ rakudo: 3808eaa410 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files [14:19] ¦ rakudo: Merge pull request #4114 from vrurg/rakudo_4108 [14:19] ¦ rakudo: [14:19] ¦ rakudo: Do all coercion type makeup within parametrization [14:19] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3808eaa410 [14:30] bisectable6: sub a(:$foo) { dd $foo }; &a.wrap: { LEAVE say now - ENTER now; callsame }; a :foo [14:30] lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight [14:30] lizmat, Output on all releases: https://gist.github.com/60706ebc4cba9d42121e9af581baba56 [14:30] lizmat, Bisecting by output (old=2020.02.1 new=2020.05.1) because on both starting points the exit code is 1 [14:30] lizmat, bisect log: https://gist.github.com/e6b17a3bd5ba508cdddab6704a393941 [14:30] lizmat, (2020-02-27) https://github.com/rakudo/rakudo/commit/4f63764c827f8503db27612df5d4c09823d59745 [14:30] lizmat, Bisecting by output (old=2018.03 new=2018.04.1) because on both starting points the exit code is 1 [14:31] lizmat, bisect log: https://gist.github.com/b0939ac45971783cb8318f5c2bcbf593 [14:31] lizmat, (2018-04-21) https://github.com/rakudo/rakudo/commit/4b5d36f3a8dff65cb41d4c3747c3f15e6fa36cbb [14:31] lizmat, Bisecting by output (old=2018.02.1 new=2018.03) because on both starting points the exit code is 1 [14:31] lizmat, bisect log: https://gist.github.com/28bd1ceb5013cf74c3269e39a8718a61 [14:31] lizmat, (2018-03-02) https://github.com/rakudo/rakudo/commit/440fceacc2e2b31484aaa5890741a92d8759d737 [14:31] lizmat, Bisecting by output (old=2018.01 new=2018.02.1) because on both starting points the exit code is 1 [14:32] lizmat, bisect log: https://gist.github.com/e500af03d69b502de23a75a988e4717e [14:32] lizmat, (2018-01-30) https://github.com/rakudo/rakudo/commit/58de239cc90bb3a26a055dd4f7d70c055bee20ae [14:32] lizmat, Output on all releases and bisected commits: https://gist.github.com/bba503d79d7eeccd0a9215e7a104f2e3 [14:34] m: sub a(:$foo) { dd $foo }; &a.wrap: -> | { LEAVE say now - ENTER now; callsame }; a :foo # apparently the block should just accept everything to make that work [14:34] rakudo-moar 3808eaa41: OUTPUT: «Bool::True␤0.0030628␤» [14:54] *** b2gills left [15:00] Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: https://github.com/rakudo/rakudo/wiki/ChangeLog-Draft [15:20] vrurg: why does b5465b1769 fix #4108? [15:20] (2020-12-14) https://github.com/rakudo/rakudo/commit/b5465b1769 Do all coercion type makeup within parametrization [15:21] nine: because a call to CoercionHOW compose was missing in on two paths. [15:22] Neither patch nor commit message make that clear [15:23] Argh, right... [15:24] I was too focused on what's been done and under some time pressure too. [15:24] There shouldn't be any time pressure [15:27] *** b2gills joined [15:28] nine: Agree. But that why we eventually need better review process. A mistake can take place any time. [15:28] I don't see how that's connected? [15:33] nine: A reviewer could've spotted bad commit message before PR merging when it's not too late to fix it. [15:34] Yes. So why did you merge it not half a day after opening it? [15:40] Because too often no reviews happens and I felt that the bug is rather severe to be fixed ASAP. But it's only explanation, not an excuse. I agree, I must've let it wait for longer. [15:41] Seems to me the review process itself is fine :) We just have to stick to it [15:42] If a bug is actually time critical (what makes it so?), the best course of action is to simply revert the change that introduced it and work on the fix without pressure. [15:43] nine, I think "time critical" is implied by the release date in 4 days. Which can be stretched and all, of course, but humans are not always perfectly rational. [15:46] That's excatly what I was trying to get that. Regular, frequent releases are done for the sole purpose of avoiding the "need to get this in in time for the release" rush. They do so because if the next release is up in a month anyway, not much is lost by missing one of them. [15:47] For regressions that pop up during release testing, reverting the change is always the safe option. All that means is that a new feature will be delayed by just a month. And it obviously wasn't ready for prime time anyway. [15:47] Besides, 4 days is enough to review a single rather short PR. [15:57] *** patrickb joined [16:02] For my own PRs I'm acquiring a habit of giving them a week, then ask here if anyone's planning to do a review and then merge them. [16:02] o/ Chiming in on the discussion. How much additional work would consequently using a release branch be? I.e. create a branch a week before the release or so and do the revert only there. [16:03] And everytime I feel a little frustration coming up because my PRs sit there unreviewed, I start reviewing other PRs. Because....it's hard to feel entitled when I don't do my share :) [16:03] I suspect a golden rule would need to be, to never do complex stuff on the release branch. [16:04] I thought we already do release branches? [16:05] I just derive a branch from the commit fitting. [16:06] Actually I noticed a recent trend to give the PRs more love. I really like that. nine++, jnthn++ (I may be missing someone) Thank you! [16:07] * sena_kun goes afk [16:13] Speaking of giving them 1 week. It's about time for: https://github.com/Raku/nqp/pull/687 [16:13] Anyone wants to take a look? [16:16] looks reasonable to me [16:20] ¦ nqp/fix-multithreaded-compilation-issues: 4 commits pushed by (Stefan Seifert)++ [16:20] ¦ nqp/fix-multithreaded-compilation-issues: 71e9dbc010 | Fix parallel compilation occasionally losing frames [16:20] ¦ nqp/fix-multithreaded-compilation-issues: 0845c3858d | Remove long obsolete code [16:20] ¦ nqp/fix-multithreaded-compilation-issues: f0b8724e13 | Remove superfluous setting of debugtypename on mixins [16:20] ¦ nqp/fix-multithreaded-compilation-issues: ccf510dcdd | Fix "no such attribute" errors on mixin created by concurrent code [16:20] ¦ nqp/fix-multithreaded-compilation-issues: review: https://github.com/Raku/nqp/compare/abef8549c2d1...ccf510dcddc7 [16:20] fixed a typo in a commit message [16:20] ¦ nqp/master: 5 commits pushed by (Stefan Seifert)++, niner++ [16:20] ¦ nqp/master: 71e9dbc010 | Fix parallel compilation occasionally losing frames [16:20] ¦ nqp/master: 0845c3858d | Remove long obsolete code [16:20] ¦ nqp/master: f0b8724e13 | Remove superfluous setting of debugtypename on mixins [16:20] ¦ nqp/master: ccf510dcdd | Fix "no such attribute" errors on mixin created by concurrent code [16:20] ¦ nqp/master: 04563b1c86 | Merge pull request #687 from Raku/fix-multithreaded-compilation-issues [16:20] ¦ nqp/master: review: https://github.com/Raku/nqp/compare/b12517b062d4...04563b1c86f8 [16:20] Maybe we should promote release branches more and have a well defined procedure. Initial idea: Branched a week before the planed release date ("feature freeze") and loudly announced on IRC. This would prevent features getting into the release shortly before the release, but that's probably a good thing. [16:21] patrickb: do you know much about building moarvm on windows? [16:21] Also this would move the "merge rush" a week before the release. [16:26] MasterDuke: I have done a lot of messing around in the last year. Can't claim deeper knowledge though. Do you have a link or something I can have a look at? [16:26] https://github.com/MoarVM/MoarVM/pull/1402 [16:44] m: my $a = -1/4.FatRat; my $b = 1.FatRat/2**256; use Test; say is-approx($a + $b, $a.Num + $b.Num) # this fails with `actual relative difference: 3` on the above gmp branch for some reason [16:44] rakudo-moar 3808eaa41: OUTPUT: «ok 1 - ␤True␤» [16:49] *** patrickb left [16:50] m: my $a = -1/4.FatRat; my $b = 1.FatRat/2**256; use Test; say ($a + $b) - ($a.Num + $b.Num) # because this gives `-0.75` for some reason [16:50] rakudo-moar 3808eaa41: OUTPUT: «0␤» [17:05] *** lizmat_ joined [17:09] *** Altai-man joined [17:09] *** lizmat left [17:11] *** sena_kun left [17:11] *** lizmat_ is now known as lizmat [18:46] *** domidumont left [18:56] *** MasterDuke left [18:59] *** morayj left [19:24] *** stoned75 left [19:58] *** MasterDuke joined [20:12] *** MasterDuke left [20:25] *** Xliff joined [20:30] *** squashable6 left [20:30] *** squashable6 joined [20:48] *** Altai-man left [21:00] *** MasterDuke joined [21:02] *** squashable6 left [21:04] *** squashable6 joined [22:01] *** rypervenche left [22:05] *** rypervenche joined [22:57] *** squashable6 left [22:58] *** squashable6 joined [23:58] *** Xliff left