| Geth | rakudo: Xliff++ created pull request #4113: Displays default values for parameters in sub MAIN |
00:35 | |
|
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:04 | |
|
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' github.com/rakudo/rakudo/issues/4115 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:00 | |
|
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]: github.com/rakudo/rakudo/issues/4108 [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: gist.github.com/60706ebc4cba9d4212...f581baba56 | |||
| 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: gist.github.com/e6b17a3bd5ba508cdd...704a393941 | |||
| lizmat, (2020-02-27) github.com/rakudo/rakudo/commit/4f...9823d59745 | |||
| lizmat, Bisecting by output (old=2018.03 new=2018.04.1) because on both starting points the exit code is 1 | |||
| lizmat, bisect log: gist.github.com/b0939ac45971783cb8...5c2bcbf593 | 14:31 | ||
| lizmat, (2018-04-21) github.com/rakudo/rakudo/commit/4b...5e6fa36cbb | |||
| lizmat, Bisecting by output (old=2018.02.1 new=2018.03) because on both starting points the exit code is 1 | |||
| lizmat, bisect log: gist.github.com/28bd1ceb5013cf74c3...39a8718a61 | |||
| lizmat, (2018-03-02) github.com/rakudo/rakudo/commit/44...2d8759d737 | |||
| lizmat, Bisecting by output (old=2018.01 new=2018.02.1) because on both starting points the exit code is 1 | |||
| lizmat, bisect log: gist.github.com/e500af03d69b502de2...a988e4717e | 14:32 | ||
| lizmat, (2018-01-30) github.com/rakudo/rakudo/commit/58...055bee20ae | |||
| lizmat, Output on all releases and bisected commits: gist.github.com/bba503d79d7eeccd0a...e7a104f2e3 | |||
| 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 0.0030628 |
||
|
14:54
b2gills left
|
|||
| releasable6 | Next release in ā4 days and ā3 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 15:00 | |
| nine | vrurg: why does b5465b1769 fix #4108? | 15:20 | |
| linkable6 | (2020-12-14) github.com/rakudo/rakudo/commit/b5465b1769 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. Because....it'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: github.com/Raku/nqp/pull/687 | 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 | ||
| MasterDuke | github.com/MoarVM/MoarVM/pull/1402 | ||
| 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 - True |
||
|
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
|
|||