[00:18] *** nuno left
[05:52] *** hurufu joined
[06:50] *** timo left
[06:58] *** iwuvmika left
[07:12] *** iwuvmika joined
[07:21] <ab5tract> lizmat: Stop merging without review\

[07:21] <ab5tract> "RakuAST: streamline RakuAST type lookup" <--- this helps a "bit"? so why

[07:22] <ab5tract> why can't we please have nice readable code in core

[07:22] <ab5tract> 3-5 days without review does not equal a review

[07:23] <ab5tract> either we play by the rules you proposed or we don't 

[07:24] <ab5tract> *Please stop

[07:30] <japhb> ab5tract: I am currently working on the codification of these rules (now that my previous big commitment is out of the way), so this is particular relevant to my thoughts.

[07:30] <japhb> What is your proposal for dealing with review Warnocking?

[07:31] <ab5tract> is that when PRs sit idle without review?

[07:32] <lizmat> yes

[07:32] <japhb> https://en.wikipedia.org/wiki/Warnock's_dilemma

[07:33] <ab5tract> Our person power is miniscule. As of right now, there are roughly two core devs with significant commits in the last 6-8 weeks, right?

[07:33] <ab5tract> And one has gone inactive, perhaps over fallout from similar lines of discussion

[07:34] <ab5tract> I am tempted to say that Warnocking isn't even a question until your PR age hits the median of age of open PRs

[07:35] <ab5tract> or at least pinged someone for review outside of the github interface

[07:36] <ab5tract> And waited a week for them to have time

[07:36] <ab5tract> Security patches and other urgent matters aside

[07:36] <japhb> lizmat has tagged me for review in GH, but I haven't been able to do so until basically tonight

[07:37] <lizmat> median age of open PRs would come to something like 3 months

[07:37] <japhb> (for various PRs)

[07:37] <ab5tract> lizmat: but what makes any other PR be weighted less in the right to not be Warnocked?

[07:37] <lizmat> by that time nobody knows what it was about, and the Pr dies

[07:37] <ab5tract> the 3 months problem is an essential part of my point

[07:38] <ab5tract> japhb: I'm in a similar situation

[07:38] <lizmat> you mean: only if a PR is still significant after 3 months, is it worth merging ?

[07:38] <japhb> Sounds like we need DORA metrics just to discuss this from a basis in data

[07:38] <lizmat> well, whatever

[07:39] <japhb> I *think* ab5tract was talking about delay before merging an *unreviewed* PR ...?

[07:39] <lizmat> since the last time ab5tract said something about me merging things too soo, I've only merged 1 PR that I deemed essential for the next release

[07:39] <lizmat> *soon

[07:41] <japhb> ab5tract: I'm not sure if it's a source of confusion, but Geth has been reporting a lot of liz's work in branches

[07:41] <lizmat> Re Warnocking: if you receive a request for review, and don't have time, then please respond with a "I don't have time now, will look at this in X days"

[07:41] <lizmat> then at least it's clear it's not Warnocked

[07:41] <japhb> Good point.  I apologize for not having done that.

[07:45] <ab5tract> okay I see what happened. I misread which branch was in main. I took issue with lizmat-121 being "merged" without review, which it had  not been

[07:45] <lizmat> no worries, I just mentioned it so that we can maybe get used to that moving forward

[07:46] <ab5tract> *which PR was merged into main

[07:46] <lizmat> The only thing I merged was https://github.com/rakudo/rakudo/commit/b45de7d85a Handle dangling symlinks in IO::Path.resolve better

[07:46] <lizmat> 6913

[07:48] <ab5tract> Right, I see that now. I apologize for that, my eye slipped up a row when reading that section of scrollback

[07:48] <lizmat> and it was pointed out that there's still a way to have something look resolved when it isn't, so there's at least one more PR (and merge before release) coming for that

[07:48] <ab5tract> I was wondering if there might be a different approach to that bug report.

[07:49] <lizmat> if the confusion stems from PRs and branches being posted on #raku-dev, then maybe we should stop doing that

[07:49] <ab5tract> Or an additional one

[07:49] <ab5tract>  This is the first time I've got it wrong, but it does make what lands in main less clear given that there is by definition a slower flow of that

[07:49] <lizmat> anyways, I've stopped pushing to main completely, only done PRs 

[07:50] <lizmat> as we agreed to, so at least we know the now extended CI is green on them

[07:51] <japhb> :+1:

[08:05] <ab5tract> my apologies again for the misunderstanding this morning

[08:05] <ab5tract> but at least the Warnock discussion was a positive direction, I think

[08:06] <lizmat> sure, but this really made my day.... not  :-(

[08:07] <lizmat> but apologies accepted

[08:11] <ab5tract> bisectable6 seems to be still running with a PERL6LIB? https://gist.github.com/21d22bf5b58b8e99abf19e71871653af

[08:12] <lizmat> well, it would need to be to be able to bisect older ones ?

[08:23] <ab5tract> We could make the deprecation not fire if you have RAKULIB declared as well

[08:23] <ab5tract> it just gets a bit noisy for the bisectable case

[08:30] <lizmat> RAKULIB and PERL6LIB could be different

[08:30] <lizmat> one option would be to ignore PERL6LIB if RAKULIB is set ?

[08:36] <ab5tract> yeah, that's what I meant. PR incomming

[08:37] <ab5tract> it could either simply suppress deprecation warning

[08:38] <ab5tract> this would allow a "transition" where both RAKULIB and PERL6LIB are loaded

[08:39] <ab5tract> in fact its the behavior we have now, just without the deprecation, so I suggest we leave it as is

[08:41] <lizmat> my proposal would be:

[08:41] <lizmat> -            if nqp::existskey($ENV,'PERL6LIB') {

[08:41] <lizmat> +            elsif nqp::existskey($ENV,'PERL6LIB') {

[08:42] <lizmat> clean and simple: if you have RAKULIB specified, ignore PERL6LIB

[08:43] <ab5tract> that's fair, but it does change base behavior

[08:43] <lizmat> if you specified RAKULIB and PERL6LIB with different paths you mean?

[08:43] <ab5tract> right now if you have RAKUDOLIB RAKULIB and PERL6LIB defined, they all get loaded

[08:43] <lizmat> yes

[08:43] <lizmat> and I would say for the latter two, that's DIHWIDT

[08:44] <lizmat> but yeah, that would change

[08:44] <lizmat> why would one specify both the old and the new... and especially with different paths ?

[08:45] <lizmat> I mean, modules themselves shouldn't be aware of how they get reached ?

[08:45] <ab5tract> good question. one I have is, are RAKUDOLIB amnd RAKULIB synonyms?

[08:47] <lizmat> it seems to stem from f5f6f76ff1fbb23e70

[08:47] <linkable6> (2020-02-13) https://github.com/rakudo/rakudo/commit/f5f6f76ff1 Renaming of perl6 to rakudo

[08:48] <ab5tract> so, synonyms. but they don't act like synonyms in the code. it really should be elsif all the way down

[08:48] <lizmat> then cc165a0533f5f3e25a made them mutually exclusive

[08:48] <linkable6> (2020-02-27) https://github.com/rakudo/rakudo/commit/cc165a0533 Modify or delete certain environment variables

[08:49] <lizmat> then 1fd660a921a8f1e96a 

[08:49] <linkable6> (2020-02-27) https://github.com/rakudo/rakudo/commit/1fd660a921 ensure RAKUDOLIB is always respected

[08:49] <japhb> RAKULIB should apply to *any* Raku compiler, and RAKUDOLIB should only be respected by Rakudo

[08:49] <lizmat> commit message was wrong, this was about RAKULIB

[08:49] <lizmat> then 30a3186b94b02b04c4c5 

[08:49] <linkable6> (2020-02-28) https://github.com/rakudo/rakudo/commit/30a3186b94 respect all three module path env vars\n\nensure precedence is RAKUDOLIB, RAKULIB, PERL6LIB

[08:52] <ab5tract> ok, since we have a crumb trail I'll go with the minimalist impact.

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: 1b101fa30a | ab5tract++ | 2 files

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: Suppress PERL6LIB deprecations for some situations

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: 

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: Specifically, suppress the deprecations in the case

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: that the user has already specified one of the

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: non-deprecated environment variables.

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: 

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: Users that have multiple set must already be in a

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: <…commit message has 6 more lines…>

[08:56] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: review: https://github.com/rakudo/rakudo/commit/1b101fa30a

[08:57] <Geth> ¦ rakudo: ab5tract++ created pull request #6919: Suppress PERL6LIB deprecations for some situations

[08:57] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6919

[08:58] <lizmat> ab5tract: I think something crept into that PR

[09:00] <ab5tract> the one time I dont use git add -i

[09:01] <lizmat> Pro Tip: always do a "git diff" before a commit   :-)

[09:03] <japhb> alias gdc='git diff --cached'  # What you're actually about to commit

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: 818af65dde | ab5tract++ | src/core.c/CompUnit/RepositoryRegistry.rakumod

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: Suppress PERL6LIB deprecations for some situations

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: 

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: Specifically, suppress the deprecations in the case

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: that the user has already specified one of the

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: non-deprecated environment variables.

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: 

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: Users that have multiple set must already be in a

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: <…commit message has 6 more lines…>

[09:03] <Geth> ¦ rakudo/ab5tract/silence-perl6lib: review: https://github.com/rakudo/rakudo/commit/818af65dde

[09:03] <lizmat> japhb++

[09:03] <ab5tract> My only git alias is g=git

[09:04] <ab5tract> as mentioned, g add -i is my goto. I can stage, revert, and diff all day long :)

[09:05] <ab5tract> Anyway, fixed now. lizmat do you know how to turn off the branch announcements for geth? I don't think I am an admin of the github project

[09:06] <japhb> Hmmm, should we have some other place for those announcements to go?

[09:06] <japhb> Maybe a #raku-prs or similar?

[09:07] <japhb> If we stick with everything going via PR, the channel noise level is going to go up a lot as PRs get updated, for instance

[09:07] <ab5tract> but the review link is to a commit, rather than a PR

[09:08] <lizmat> Guess I should pick up my "replace Geth" project again

[09:15] <ab5tract> Can the replacement be named Garth? There's just something about that name that

[09:17] <ab5tract> *I enjoy

[09:23] <japhb> Party on

[09:23] <ab5tract> :)

[09:23] <ab5tract> We're defioitely not worthy

[10:49] *** samebchase left
[10:50] *** samebchase joined
[11:13] <Geth> ¦ rakudo/lizmat-123: bfd95e7718 | (Elizabeth Mattijsen)++ | 2 files

[11:13] <Geth> ¦ rakudo/lizmat-123: RakuAST: remove initialization for "my int $a = 0"

[11:13] <Geth> ¦ rakudo/lizmat-123: 

[11:13] <Geth> ¦ rakudo/lizmat-123: Because natives are initialized with their base value, there is no

[11:13] <Geth> ¦ rakudo/lizmat-123: need to actually create bytecode to do that.

[11:13] <Geth> ¦ rakudo/lizmat-123: 

[11:13] <Geth> ¦ rakudo/lizmat-123: Pro: one can write "my int $foo = 0" for clarity without losing the

[11:13] <Geth> ¦ rakudo/lizmat-123:      possible performance benefit of skipping the QAST code for

[11:13] <Geth> ¦ rakudo/lizmat-123: <…commit message has 32 more lines…>

[11:13] <Geth> ¦ rakudo/lizmat-123: review: https://github.com/rakudo/rakudo/commit/bfd95e7718

[11:13] <Geth> ¦ rakudo: lizmat++ created pull request #6920: RakuAST: remove initialization for "my int $a = 0"

[11:13] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6920

[12:50] <Geth> ¦ rakudo/lizmat-124: 098c33ecf5 | (Elizabeth Mattijsen)++ | src/core.c/ThreadPoolScheduler.rakumod

[12:50] <Geth> ¦ rakudo/lizmat-124: Cancelletion.new defaults to empty async_handles

[12:50] <Geth> ¦ rakudo/lizmat-124: 

[12:50] <Geth> ¦ rakudo/lizmat-124: So there's no need to specify that in any calls that don't actually

[12:50] <Geth> ¦ rakudo/lizmat-124: need any async_handles

[12:50] <Geth> ¦ rakudo/lizmat-124: review: https://github.com/rakudo/rakudo/commit/098c33ecf5

[12:50] <Geth> ¦ rakudo: lizmat++ created pull request #6921: Cancelletion.new defaults to empty async_handles

[12:50] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6921

[13:23] *** Voldenet left
[13:34] *** Voldenet joined
[14:26] *** djinni` left
[14:40] *** djinni` joined
[15:45] <Geth> ¦ rakudo/lizmat-125: 89bd118fe0 | (Elizabeth Mattijsen)++ | 7 files

[15:45] <Geth> ¦ rakudo/lizmat-125: De-nqp-ify outer nqp::stmts from methods

[15:45] <Geth> ¦ rakudo/lizmat-125: 

[15:45] <Geth> ¦ rakudo/lizmat-125: Historically there was an advantage to having the outer scope of

[15:45] <Geth> ¦ rakudo/lizmat-125: a block be an nqp::stmts.  This isn't the case anymore, unless for

[15:45] <Geth> ¦ rakudo/lizmat-125: special reasons (such a not wanting to sink a value).

[15:45] <Geth> ¦ rakudo/lizmat-125: 

[15:45] <Geth> ¦ rakudo/lizmat-125: This commit removes the outer nqp::stmts of blocks where appropriate:

[15:45] <Geth> ¦ rakudo/lizmat-125: <…commit message has 12 more lines…>

[15:45] <Geth> ¦ rakudo/lizmat-125: review: https://github.com/rakudo/rakudo/commit/89bd118fe0

[15:45] <Geth> ¦ rakudo: lizmat++ created pull request #6922: De-nqp-ify outer nqp::stmts from methods

[15:45] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6922

[15:51] *** hurufu left
[15:52] *** hurufu joined