00:18 nuno left 05:52 hurufu joined 06:50 timo left 06:58 iwuvmika left 07:12 iwuvmika joined
ab5tract lizmat: Stop merging without review\ 07:21
"RakuAST: streamline RakuAST type lookup" <--- this helps a "bit"? so why
why can't we please have nice readable code in core 07:22
3-5 days without review does not equal a review
either we play by the rules you proposed or we don't 07:23
*Please stop 07:24
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
What is your proposal for dealing with review Warnocking?
ab5tract is that when PRs sit idle without review? 07:31
lizmat yes 07:32
japhb en.wikipedia.org/wiki/Warnock's_dilemma
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
And one has gone inactive, perhaps over fallout from similar lines of discussion
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:34
or at least pinged someone for review outside of the github interface 07:35
And waited a week for them to have time 07:36
Security patches and other urgent matters aside
japhb lizmat has tagged me for review in GH, but I haven't been able to do so until basically tonight
lizmat median age of open PRs would come to something like 3 months 07:37
japhb (for various PRs)
ab5tract lizmat: but what makes any other PR be weighted less in the right to not be Warnocked?
lizmat by that time nobody knows what it was about, and the Pr dies
ab5tract the 3 months problem is an essential part of my point
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 ?
japhb Sounds like we need DORA metrics just to discuss this from a basis in data
lizmat well, whatever
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
*soon
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"
then at least it's clear it's not Warnocked
japhb Good point. I apologize for not having done that.
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
ab5tract *which PR was merged into main 07:46
lizmat The only thing I merged was github.com/rakudo/rakudo/commit/b45de7d85a Handle dangling symlinks in IO::Path.resolve better
6913
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
ab5tract I was wondering if there might be a different approach to that bug report.
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
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
lizmat anyways, I've stopped pushing to main completely, only done PRs
as we agreed to, so at least we know the now extended CI is green on them 07:50
japhb :+1: 07:51
ab5tract my apologies again for the misunderstanding this morning 08:05
but at least the Warnock discussion was a positive direction, I think
lizmat sure, but this really made my day.... not :-( 08:06
but apologies accepted 08:07
ab5tract bisectable6 seems to be still running with a PERL6LIB? gist.github.com/21d22bf5b58b8e99ab...71871653af 08:11
lizmat well, it would need to be to be able to bisect older ones ? 08:12
ab5tract We could make the deprecation not fire if you have RAKULIB declared as well 08:23
it just gets a bit noisy for the bisectable case
lizmat RAKULIB and PERL6LIB could be different 08:30
one option would be to ignore PERL6LIB if RAKULIB is set ?
ab5tract yeah, that's what I meant. PR incomming 08:36
it could either simply suppress deprecation warning 08:37
this would allow a "transition" where both RAKULIB and PERL6LIB are loaded 08:38
in fact its the behavior we have now, just without the deprecation, so I suggest we leave it as is 08:39
lizmat my proposal would be: 08:41
- if nqp::existskey($ENV,'PERL6LIB') {
+ elsif nqp::existskey($ENV,'PERL6LIB') {
clean and simple: if you have RAKULIB specified, ignore PERL6LIB 08:42
ab5tract that's fair, but it does change base behavior 08:43
lizmat if you specified RAKULIB and PERL6LIB with different paths you mean?
ab5tract right now if you have RAKUDOLIB RAKULIB and PERL6LIB defined, they all get loaded
lizmat yes
and I would say for the latter two, that's DIHWIDT
but yeah, that would change 08:44
why would one specify both the old and the new... and especially with different paths ?
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?
lizmat it seems to stem from f5f6f76ff1fbb23e70 08:47
linkable6 (2020-02-13) github.com/rakudo/rakudo/commit/f5f6f76ff1 Renaming of perl6 to rakudo
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
linkable6 (2020-02-27) github.com/rakudo/rakudo/commit/cc165a0533 Modify or delete certain environment variables
lizmat then 1fd660a921a8f1e96a 08:49
linkable6 (2020-02-27) github.com/rakudo/rakudo/commit/1fd660a921 ensure RAKUDOLIB is always respected
japhb RAKULIB should apply to *any* Raku compiler, and RAKUDOLIB should only be respected by Rakudo
lizmat commit message was wrong, this was about RAKULIB
then 30a3186b94b02b04c4c5
linkable6 (2020-02-28) github.com/rakudo/rakudo/commit/30a3186b94 respect all three module path env vars\n\nensure precedence is RAKUDOLIB, RAKULIB, PERL6LIB
ab5tract ok, since we have a crumb trail I'll go with the minimalist impact. 08:52
Geth rakudo/ab5tract/silence-perl6lib: 1b101fa30a | ab5tract++ | 2 files
Suppress PERL6LIB deprecations for some situations

Specifically, suppress the deprecations in the case that the user has already specified one of the non-deprecated environment variables.
Users that have multiple set must already be in a ... (6 more lines)		 08:56
rakudo: ab5tract++ created pull request #6919:
Suppress PERL6LIB deprecations for some situations		 08:57
lizmat ab5tract: I think something crept into that PR 08:58
ab5tract the one time I dont use git add -i 09:00
lizmat Pro Tip: always do a "git diff" before a commit :-) 09:01
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
Suppress PERL6LIB deprecations for some situations

Specifically, suppress the deprecations in the case that the user has already specified one of the non-deprecated environment variables.
Users that have multiple set must already be in a ... (6 more lines)
lizmat japhb++
ab5tract My only git alias is g=git
as mentioned, g add -i is my goto. I can stage, revert, and diff all day long :) 09:04
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:05
japhb Hmmm, should we have some other place for those announcements to go? 09:06
Maybe a #raku-prs or similar?
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
lizmat Guess I should pick up my "replace Geth" project again 09:08
ab5tract Can the replacement be named Garth? There's just something about that name that 09:15
*I enjoy 09:17
japhb Party on 09:23
ab5tract :)
We're defioitely not worthy
10:49 samebchase left 10:50 samebchase joined
Geth rakudo/lizmat-123: bfd95e7718 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: remove initialization for "my int $a = 0"

Because natives are initialized with their base value, there is no need to actually create bytecode to do that.
Pro: one can write "my int $foo = 0" for clarity without losing the
   possible performance benefit of skipping the QAST code for
... (32 more lines)		 11:13
rakudo: lizmat++ created pull request #6920:
RakuAST: remove initialization for "my int $a = 0"
rakudo/lizmat-124: 098c33ecf5 | (Elizabeth Mattijsen)++ | src/core.c/ThreadPoolScheduler.rakumod
Cancelletion.new defaults to empty async_handles

So there's no need to specify that in any calls that don't actually need any async_handles		 12:50
rakudo: lizmat++ created pull request #6921:
Cancelletion.new defaults to empty async_handles
13:23 Voldenet left 13:34 Voldenet joined 14:26 djinni` left 14:40 djinni` joined
Geth rakudo/lizmat-125: 89bd118fe0 | (Elizabeth Mattijsen)++ | 7 files
De-nqp-ify outer nqp::stmts from methods

Historically there was an advantage to having the outer scope of a block be an nqp::stmts. This isn't the case anymore, unless for special reasons (such a not wanting to sink a value).
This commit removes the outer nqp::stmts of blocks where appropriate: ... (12 more lines)		 15:45
rakudo: lizmat++ created pull request #6922:
De-nqp-ify outer nqp::stmts from methods
15:51 hurufu left 15:52 hurufu joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!