[06:40] <[Tux]> Is JJ (Juan Julian) here too?

[07:33] <ab5tract> I’m late to comment but I think that calling a range “valid” when it will never produce a range of numbers is absolutely wrong

[07:34] <ab5tract> That’s Perl logic

[07:34] <ab5tract> I don’t see any cause to keep this behavior in 6.e

[07:35] <ab5tract> It’s a tiny change to RakuAST to address this

[07:36] <ab5tract> Honestly, it’s this kind of “it’s an invalid valid” behavior that makes people bounce off of Raku (and for very good reason imo)

[07:37] <ab5tract> ShimmerFairy: if you want to add a sanity check to the range class in RakuAST, I would vociferously support your PR

[08:03] *** zostay_ joined
[08:05] *** summerisle_ joined
[08:09] *** zostay left
[08:09] *** summerisle left
[08:09] *** zostay_ is now known as zostay

[08:12] *** hankache left
[08:14] <[Tux]> ===(    9109;2  4559/?  0/?  0/? )======================================Potential difficulties:

[08:14] <[Tux]>     Useless use of constant integer 1 in sink context

[08:14] <[Tux]>     at t/75_hashref.t:33

[08:14] <[Tux]>     ------>     CATCH { default { $e = $_; <HERE>1; }}

[08:14] <[Tux]> just remove the `1;` ?

[08:30] <lizmat> or make it return 1 ?

[08:30] <lizmat> not sure what the 1 was supposed to mean?

[08:51] <[Tux]> neither do I  :)

[08:52] <lizmat> what's the API of the sub with the CATCH in it?

[08:52] <[Tux]> it is in a test file. looking right now ...

[08:54] <[Tux]> weird: not in the source code at all

[08:55] <[Tux]> ignore that

[08:55] <lizmat> ah, just remove the 1

[08:55] <lizmat> indeed has no function there

[08:57] <[Tux]> removed and pushed

[09:13] *** Voldenet left
[10:23] *** Voldenet joined
[10:25] <lizmat> c: HEAD use v6.*; my @a := [1,[2,[3,4]]]; @a[||("1",)] := 42; dd @a

[10:25] <committable6> lizmat, ¦HEAD(25984bb): «Cannot bind to Array slice␤  in block <unit> at /tmp/k0dX0UrTB5 line 1␤␤ «exit code = 1»»

[10:25] <lizmat> c: HEAD use v6.*; my @a := [1,[2,[3,4]]]; @a[||(1,)] := 42; dd @a

[10:25] <committable6> lizmat, ¦HEAD(25984bb): «[1, 42]␤»

[10:25] <lizmat> meh

[10:34] <ShimmerFairy> Thinking about the Range stuff, I don't think we could outright ban all backwards ranges, since then we'd need to come up with a new way of modeling "a range of zero elements". I think my only concern, ultimately, is that stuff like 9^..7 indicates an expectation that won't hold. So maybe we only refuse to build backwards ranges with exclusive ends?

[10:36] <lizmat> if you're talking about 9 ^.. 7  , then we would need to build the check into infix:<^..>

[10:36] <lizmat> and I guess then only if they are literal values

[10:36] <lizmat> so maybe this needs to be a worry in the grammar ?

[10:38] <ShimmerFairy> I think checking in the constructor would be best, so that all ways of spelling a Range are checked. I don't know if there's a sensible use case for Range.new(9, 5, :excludes-max) where 9..^5 wouldn't make sense too.

[10:39] <lizmat> Again, you're talking literal values: the constructor doesn't see that

[10:40] <lizmat> and disallowing that will most likely break existing code that depends on being able to create an empty Range with such endpoints

[10:41] <lizmat> so I think a worry in the grammar is the best way forward when literal values are specified

[10:41] <lizmat> the worry could be something like: reverse Ranges are not supported, did you mean to use the sequence operator: ...

[10:42] <ShimmerFairy> I don't care about literal values in particular, just situations where $min > $max. 11..9 has surprising behavior, but the rule of "backwards ranges count as empty" is easily learned. But the fact that those ranges can still exist, holding their constructed values, means that 11^..9 comes with *additional* surprising behavior that's worth worrying about.

[10:43] <ShimmerFairy> That being said, at the very least, worrying the literal spellings of 3^..^1 etc. would be helpful since no good can come from trying to put exclusive ends on top of a backwards Range. (One could argue that literal spellings of 1..0 are a worry too, to a lesser extent.)

[10:44] <lizmat> yeah, because most likely the user intended to use ... or wasn't aware that decreasing ranges aren't a thing

[10:47] <ShimmerFairy> While backwards Range = emptiness makes enough sense overall, if a user wants to express constant emptiness you'd expect them to type something like @a[Empty] rather than @a[1..0], so that the intent is clear.

[11:37] <lizmat> m: my @a = 1; @a[0;0] = 42   # meh

[11:37] <camelia> rakudo-moar e17a1d43b: OUTPUT: «Cannot modify an immutable Int (1)␤  in block <unit> at <tmp> line 1␤␤»

[11:53] <Geth> ¦ rakudo/lizmat-78: aea709da78 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod

[11:53] <Geth> ¦ rakudo/lizmat-78: Fix Any:D.AT-POS() candidate

[11:53] <Geth> ¦ rakudo/lizmat-78: 

[11:53] <Geth> ¦ rakudo/lizmat-78: It wasn't returning a container if called on a container.  Also

[11:53] <Geth> ¦ rakudo/lizmat-78: remove the "is raw" trait on an AT-POS candidate that will never

[11:53] <Geth> ¦ rakudo/lizmat-78: return anyway.

[11:53] <Geth> ¦ rakudo/lizmat-78: review: https://github.com/rakudo/rakudo/commit/aea709da78

[11:53] <Geth> ¦ rakudo: lizmat++ created pull request #6853: Fix Any:D.AT-POS() candidate

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

[13:14] <Geth> ¦ rakudo/lizmat-79: ebcb78ebb3 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod

[13:14] <Geth> ¦ rakudo/lizmat-79: Make sure dd() properly reports on caller's scope

[13:14] <Geth> ¦ rakudo/lizmat-79: 

[13:14] <Geth> ¦ rakudo/lizmat-79: Looks like legacy actually removed the frame of the "else" in which

[13:14] <Geth> ¦ rakudo/lizmat-79: the reporting lived: RakuAST needed an extra level.

[13:14] <Geth> ¦ rakudo/lizmat-79: 

[13:14] <Geth> ¦ rakudo/lizmat-79: Fix this more generally by making sure that if no arguments are

[13:14] <Geth> ¦ rakudo/lizmat-79: specified, the reporting is done from the sub's scope itself.

[13:14] <Geth> ¦ rakudo/lizmat-79: 

[13:14] <Geth> ¦ rakudo/lizmat-79: This fixes the issue for core's built with legacy, as well as with

[13:14] <Geth> ¦ rakudo/lizmat-79: RakuAST.  And if in the future "else" scopes will also be optimized

[13:14] <Geth> ¦ rakudo/lizmat-79: away, then this will continue to work properly.

[13:14] <Geth> ¦ rakudo/lizmat-79: review: https://github.com/rakudo/rakudo/commit/ebcb78ebb3

[13:15] <Geth> ¦ rakudo: lizmat++ created pull request #6854: Make sure dd() properly reports on caller's scope

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

[13:16] <Geth> ¦ rakudo/main: cfb221c3e2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Any.rakumod

[13:16] <Geth> ¦ rakudo/main: Fix Any:D.AT-POS() candidate (#6853)

[13:16] <Geth> ¦ rakudo/main: 

[13:16] <Geth> ¦ rakudo/main: It wasn't returning a container if called on a container.  Also

[13:16] <Geth> ¦ rakudo/main: remove the "is raw" trait on an AT-POS candidate that will never

[13:16] <Geth> ¦ rakudo/main: return anyway.

[13:16] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/cfb221c3e2

[13:28] <Geth> ¦ roast: bed6022ba0 | (Elizabeth Mattijsen)++ | S09-multidim/XX-POS-on-undimensioned.t

[13:28] <Geth> ¦ roast: Add test for https://github.com/rakudo/rakudo/commit/cfb221c3e2

[13:28] <Geth> ¦ roast: review: https://github.com/Raku/roast/commit/bed6022ba0

[13:33] <[Coke]> Release tentatively scheduled for a week from Saturday. No hiccups on any commits so far in blin

[13:33] <[Coke]> releasable6: next

[13:33] <releasable6> [Coke], Next release in ≈9 days and ≈5 hours. There are no known blockers. 46 out of 184 commits logged

[13:33] <releasable6> [Coke], Details: https://gist.github.com/f1898250f4bce4b8bdf9e6cb23299bc1

[13:39] <[Coke]> Are we good with everything that's been merged so far, anything that is a must-have for .10 that isn't in yet? (I wonder if we should have a tag for PRs to show if we want them in release X)

[13:40] <[Coke]> (I guess that tag is just blocker, actually)

[15:48] <Geth> ¦ rakudo/main: 7373bf69e8 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Any.rakumod

[15:48] <Geth> ¦ rakudo/main: Make sure dd() properly reports on caller's scope (#6854)

[15:48] <Geth> ¦ rakudo/main: 

[15:48] <Geth> ¦ rakudo/main: Looks like legacy actually removed the frame of the "else" in which

[15:48] <Geth> ¦ rakudo/main: the reporting lived: RakuAST needed an extra level.

[15:48] <Geth> ¦ rakudo/main: 

[15:48] <Geth> ¦ rakudo/main: Fix this more generally by making sure that if no arguments are

[15:48] <Geth> ¦ rakudo/main: specified, the reporting is done from the sub's scope itself.

[15:48] <Geth> ¦ rakudo/main: 

[15:48] <Geth> ¦ rakudo/main: This fixes the issue for core's built with legacy, as well as with

[15:48] <Geth> ¦ rakudo/main: RakuAST.  And if in the future "else" scopes will also be optimized

[15:48] <Geth> ¦ rakudo/main: away, then this will continue to work properly.

[15:48] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/7373bf69e8

[16:26] <Geth> ¦ rakudo/lizmat-64: 48aed24ced | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod

[16:26] <Geth> ¦ rakudo/lizmat-64: Oops, forgot one "int"

[16:26] <Geth> ¦ rakudo/lizmat-64: review: https://github.com/rakudo/rakudo/commit/48aed24ced

[16:29] <Geth> ¦ rakudo/main: a3e3686389 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files

[16:29] <Geth> ¦ rakudo/main: RakuAST: create ::IfUnless base class (#6831)

[16:29] <Geth> ¦ rakudo/main: 

[16:29] <Geth> ¦ rakudo/main: The handling of RakuAST::StatementModifier::If and ::Unless differ

[16:29] <Geth> ¦ rakudo/main: only in the nqp op that generates the QAST.  Instead ::Unless doing

[16:29] <Geth> ¦ rakudo/main: a cat-license of ::If, create a base class ::IfUnless referring to

[16:29] <Geth> ¦ rakudo/main: a method that provides the op-name, and make ::If and ::Unless

[16:29] <Geth> ¦ rakudo/main: provide the correct op name.

[16:29] <Geth> ¦ rakudo/main: 

[16:29] <Geth> ¦ rakudo/main: This also allows some conditions /base and /var-loweing to be

[16:29] <Geth> ¦ rakudo/main: simplified.

[16:29] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/a3e3686389

[16:30] <Geth> ¦ rakudo/main: 4872dd8950 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod

[16:30] <Geth> ¦ rakudo/main: RakuAST: add base class RakuAST::MetaInfix::CrossZip (#6834)

[16:30] <Geth> ¦ rakudo/main: 

[16:30] <Geth> ¦ rakudo/main: The logic of RakuAST::MetaInfix::Cross and RakuAST::MetaInfix::Zip

[16:30] <Geth> ¦ rakudo/main: are identical, except for three values:

[16:30] <Geth> ¦ rakudo/main: 

[16:30] <Geth> ¦ rakudo/main: - action ('cross with' | 'zip with')

[16:30] <Geth> ¦ rakudo/main: - metaop ('X' | 'Z')

[16:30] <Geth> ¦ rakudo/main: <…commit message has 11 more lines…>

[16:30] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/4872dd8950

[16:38] *** finanalyst joined
[16:47] <ab5tract> now that RAKUDO_RAKUAST is full-on, maybe we could start using some DEPARSE magic in choice places... for example, in the default usage handler

[16:47] <lizmat> pretty sure the AST is gone by that time ?

[16:48] <ab5tract> well I managed it with whatevercodes

[16:48] <lizmat> ok, maybe I'm not understanding ?

[16:48] <ab5tract> I'm pretty sure we can now surface where clauses in the usage handler

[16:49] <ab5tract> so that you can actually see what the rejection criteria is

[16:50] <lizmat> well, if you can, more power to you!   :-)

[16:50] <Geth> ¦ rakudo/main: 8d60a82737 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 4 files

[16:50] <Geth> ¦ rakudo/main: RakuAST: nqp::objprimspec can handle nqp::null (#6832)

[16:50] <Geth> ¦ rakudo/main: 

[16:50] <Geth> ¦ rakudo/main: So there is no need to extra guard against this eventuality.

[16:50] <Geth> ¦ rakudo/main: 

[16:50] <Geth> ¦ rakudo/main: Also slightly re-arrange some if's into ternaries

[16:50] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/8d60a82737

[16:54] <lizmat> m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^500000; say now - ENTER now

[16:54] <camelia> rakudo-moar e17a1d43b: OUTPUT: «0.296980531␤»

[16:54] <lizmat> m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||<1 1 1>] for ^500000; say now - ENTER now

[16:55] <camelia> rakudo-moar e17a1d43b: OUTPUT: «0.276994147␤»

[16:55] <lizmat> m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^1000000; say now - ENTER now

[16:55] <camelia> rakudo-moar e17a1d43b: OUTPUT: «0.54141459␤»

[16:55] <lizmat> m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||<1 1 1>] for ^1000000; say now - ENTER now

[16:55] <camelia> rakudo-moar e17a1d43b: OUTPUT: «0.536706294␤»

[16:56] <lizmat> argh

[16:56] <lizmat> c: HEAD use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^1000000; say now - ENTER now

[16:56] <committable6> lizmat, ¦HEAD(8d60a82): «No build for this commit»

[16:56] <lizmat> c: HEAD~1 use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^1000000; say now - ENTER now

[16:56] <committable6> lizmat, ¦HEAD~1: «1.666141178␤»

[16:56] <lizmat> c: HEAD~1 use v6.*; my @a := [1, [2, [3,4]]]; @a[||<1 1 1>] for ^1000000; say now - ENTER now

[16:56] <committable6> lizmat, ¦HEAD~1: «1.237835858␤»

[16:57] <lizmat> so why is a list of allomorphs faster than a list of ints ?

[16:58] <lizmat> it's because currently <1 1 1> is qasted as a WVal, and 1,1,1 is QASTed as infix:<,>(1,1,1)

[16:59] <Geth> ¦ rakudo/main: fba5df0890 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files

[16:59] <Geth> ¦ rakudo/main: RakuAST: make several lookup tables compile-time (#6836)

[16:59] <Geth> ¦ rakudo/main: 

[16:59] <Geth> ¦ rakudo/main: So that they don't need to be initialized every time they are about

[16:59] <Geth> ¦ rakudo/main: to be accessed.

[16:59] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/fba5df0890

[17:00] <Geth> ¦ rakudo/main: 72076fa94e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod

[17:00] <Geth> ¦ rakudo/main: RakuAST: replace variable by literal (#6837)

[17:00] <Geth> ¦ rakudo/main: 

[17:00] <Geth> ¦ rakudo/main: This variable was only initialized to zero, and then used without

[17:00] <Geth> ¦ rakudo/main: being referenced or mutated anywhere else.

[17:00] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/72076fa94e

[17:11] *** finanalyst left
[17:12] <ab5tract> but both of those look correct to me

[17:52] <Geth> ¦ rakudo/lizmat-59: 48 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++, (Will Coleda)++

[17:52] <Geth> ¦ rakudo/lizmat-59: review: https://github.com/rakudo/rakudo/compare/1cb953b3b9da...f263a8ac63c7

[17:53] <lizmat> they are both correct, but one is significantly faster than the other

[17:54] <lizmat> if infix:<,> is the core infix:<,> at compile time, then (1,1,1) can also be QASTed as a WVal

[19:28] *** hankache joined
[19:58] *** Pixi` joined
[20:01] *** Pixi left
[20:05] <Geth> ¦ rakudo/lizmat-80: 35fb7a4fdf | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod

[20:05] <Geth> ¦ rakudo/lizmat-80: Re-imagine ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE

[20:05] <Geth> ¦ rakudo/lizmat-80: 

[20:05] <Geth> ¦ rakudo/lizmat-80: - no return statements

[20:05] <Geth> ¦ rakudo/lizmat-80: - re-arranged conditions so short-circuiting can happen earler

[20:05] <Geth> ¦ rakudo/lizmat-80: - assuming it will usually work, use ifnull for condition in binding

[20:05] <Geth> ¦ rakudo/lizmat-80: review: https://github.com/rakudo/rakudo/commit/35fb7a4fdf

[20:05] <Geth> ¦ rakudo: lizmat++ created pull request #6856: Re-imagine ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE

[20:05] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6856

[20:07] <Geth> ¦ rakudo/lizmat-64: 14 commits pushed by (Elizabeth Mattijsen)++, (Will Coleda)++

[20:07] <Geth> ¦ rakudo/lizmat-64: review: https://github.com/rakudo/rakudo/compare/48aed24ced81...0674a635ef2e

[20:08] <Geth> ¦ rakudo/main: a7cbac9ecc | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | tools/build/monitor-process.pl

[20:08] <Geth> ¦ rakudo/main: Fix typo in argument handling (#6850)

[20:08] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/a7cbac9ecc

[20:09] <Geth> ¦ rakudo/main: db8e2b4179 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/variable-declaration.rakumod

[20:09] <Geth> ¦ rakudo/main: RakuAST: simplify missing initializer test (#6838)

[20:09] <Geth> ¦ rakudo/main: 

[20:09] <Geth> ¦ rakudo/main: No need to create intermediate variables

[20:09] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/db8e2b4179

[20:13] <Geth> ¦ rakudo/main: d9a5d7dd86 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/resolver.rakumod

[20:13] <Geth> ¦ rakudo/main: RakuAST: streamline ::Resolver::(EVAL|Compile) (#6842)

[20:13] <Geth> ¦ rakudo/main: 

[20:13] <Geth> ¦ rakudo/main: Specifically the .current-scope and .outer.scope methods, as these

[20:13] <Geth> ¦ rakudo/main: are pretty hot during compilation, and use atpos(..,i) vs ...[i]

[20:13] <Geth> ¦ rakudo/main: is about 2x as fast.

[20:13] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/d9a5d7dd86

[20:14] <Geth> ¦ rakudo/main: 1ca0a10077 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/resolver.rakumod

[20:14] <Geth> ¦ rakudo/main: RakuAST: streamline ::Resolver::(EVAL|Compile).find-scope-property (#6843)

[20:14] <Geth> ¦ rakudo/main: 

[20:14] <Geth> ¦ rakudo/main: Another hot method during compilation, rewritten to use atpos

[20:14] <Geth> ¦ rakudo/main: and no return statements.

[20:14] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/1ca0a10077

[20:18] <Geth> ¦ rakudo/main: 8bc8f978ba | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod

[20:18] <Geth> ¦ rakudo/main: RakuAST: optimize ::Infix.IMPL-APPLY-SINK-TO-OPERANDS (#6840)

[20:18] <Geth> ¦ rakudo/main: 

[20:18] <Geth> ¦ rakudo/main: In this relatively hot piece of code, replace for loops by native

[20:18] <Geth> ¦ rakudo/main: nqp::while and use nqp::atpos instead of postcircumfix [].  For

[20:18] <Geth> ¦ rakudo/main: reference, an nqp::while loop + nqp::atpos is about 2x as fast

[20:18] <Geth> ¦ rakudo/main: as a for loop in nqp.  That's because the iterator overhead is

[20:18] <Geth> ¦ rakudo/main: pretty big in nqp.  And using nqp ops also creates smaller bytecode

[20:18] <Geth> ¦ rakudo/main: so more chance of inlining.

[20:18] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/8bc8f978ba

[20:19] <Geth> ¦ rakudo/main: bb691c098e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod

[20:19] <Geth> ¦ rakudo/main: RakuAST: optimize ::Assignment.IMPL-APPLY-SINK-TO-OPERANDS (#6841)

[20:19] <Geth> ¦ rakudo/main: 

[20:19] <Geth> ¦ rakudo/main: In this relatively hot piece of code, replace for loops by native

[20:19] <Geth> ¦ rakudo/main: nqp::while and use nqp::atpos instead of postcircumfix [].

[20:20] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/bb691c098e

[23:27] *** coleman left
[23:27] *** apogee_ntv left
[23:44] *** coleman joined
[23:44] *** apogee_ntv joined
[23:48] *** coleman left
[23:48] *** apogee_ntv left
[23:48] *** coleman joined
[23:49] *** apogee_ntv joined