Geth rakudo: Xliff++ created pull request #4113:
Displays default values for parameters in sub MAIN
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
Geth rakudo: vrurg++ created pull request #4114:
Do all coercion type makeup within parametrization
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, sena_kun left 10:07 morayj joined 10:16 morayj_ joined 10:17 morayj left, morayj_ is now known as morayj 10:43 MasterDuke left
Geth rakudo: lizmat self-assigned successive 'use' statements in the REPL error out with 'undeclared routine'
b5465b1769 | (Vadim Belman)++ | 2 files

Don't use compose. This would also serve as a bit of optimization by reducing number of calls needed to create a coercion type.
Alongside got rid of accessing attributes via accessors and replaced with direct references. This would also remove extra method invocations.
Should fix Net::BGP, as bisected in #4108
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
linkable6 RAKUDO#4108 [open]: [BLOCKER][blin][regression] Blin 2020.12, round 3
Geth rakudo: e481619843 | (Vadim Belman)++ | src/Perl6/Metamodel/CoercionHOW.nqp
Remove a overlooked call to compose
rakudo: 3808eaa410 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #4114 from vrurg/rakudo_4108

Do all coercion type makeup within parametrization
lizmat bisectable6: sub a(:$foo) { dd $foo }; &a.wrap: { LEAVE say now - ENTER now; callsame }; a :foo 14:30
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases:
lizmat, Bisecting by output (old=2020.02.1 new=2020.05.1) because on both starting points the exit code is 1
lizmat, bisect log:
lizmat, (2020-02-27)
lizmat, Bisecting by output (old=2018.03 new=2018.04.1) because on both starting points the exit code is 1
lizmat, bisect log: 14:31
lizmat, (2018-04-21)
lizmat, Bisecting by output (old=2018.02.1 new=2018.03) because on both starting points the exit code is 1
lizmat, bisect log:
lizmat, (2018-03-02)
lizmat, Bisecting by output (old=2018.01 new=2018.02.1) because on both starting points the exit code is 1
lizmat, bisect log: 14:32
lizmat, (2018-01-30)
lizmat, Output on all releases and bisected commits:
lizmat 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
camelia Bool::True
14:54 b2gills left
releasable6 Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: 15:00
nine vrurg: why does b5465b1769 fix #4108? 15:20
linkable6 (2020-12-14) Do all coercion type makeup within parametrization
vrurg nine: because a call to CoercionHOW compose was missing in on two paths. 15:21
nine Neither patch nor commit message make that clear 15:22
vrurg Argh, right... 15:23
I was too focused on what's been done and under some time pressure too. 15:24
nine There shouldn't be any time pressure
15:27 b2gills joined
vrurg nine: Agree. But that why we eventually need better review process. A mistake can take place any time. 15:28
nine I don't see how that's connected?
vrurg nine: A reviewer could've spotted bad commit message before PR merging when it's not too late to fix it. 15:33
nine Yes. So why did you merge it not half a day after opening it? 15:34
vrurg 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:40
nine Seems to me the review process itself is fine :) We just have to stick to it 15:41
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:42
sena_kun 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:43
nine 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:46
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
vrurg Besides, 4 days is enough to review a single rather short PR.
15:57 patrickb joined
nine 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
patrickb 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.
nine And everytime I feel a little frustration coming up because my PRs sit there unreviewed, I start reviewing other PRs.'s hard to feel entitled when I don't do my share :) 16:03
patrickb I suspect a golden rule would need to be, to never do complex stuff on the release branch.
nine I thought we already do release branches? 16:04
sena_kun I just derive a branch from the commit fitting. 16:05
patrickb 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:06
sena_kun goes afk 16:07
nine Speaking of giving them 1 week. It's about time for: 16:13
Anyone wants to take a look?
MasterDuke looks reasonable to me 16:16
Geth nqp/fix-multithreaded-compilation-issues: 4 commits pushed by (Stefan Seifert)++ 16:20
nine fixed a typo in a commit message
Geth nqp/master: 5 commits pushed by (Stefan Seifert)++, niner++
patrickb 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.
MasterDuke patrickb: do you know much about building moarvm on windows? 16:21
patrickb Also this would move the "merge rush" a week before the release.
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
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
camelia ok 1 -
16:49 patrickb left
MasterDuke 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
camelia 0
17:05 lizmat_ joined 17:09 Altai-man joined, lizmat left 17:11 sena_kun left, 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, 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