[Tux] Is JJ (Juan Julian) here too? 06:40
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:33
That’s Perl logic 07:34
I don’t see any cause to keep this behavior in 6.e
It’s a tiny change to RakuAST to address this 07:35
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:36
ShimmerFairy: if you want to add a sanity check to the range class in RakuAST, I would vociferously support your PR 07:37
08:03 zostay_ joined 08:05 summerisle_ joined 08:09 zostay left, summerisle left, zostay_ is now known as zostay 08:12 hankache left
[Tux] ===( 9109;2 4559/? 0/? 0/? )======================================Potential difficulties: 08:14
Useless use of constant integer 1 in sink context
at t/75_hashref.t:33
------> CATCH { default { $e = $_; <HERE>1; }}
just remove the `1;` ?
lizmat or make it return 1 ? 08:30
not sure what the 1 was supposed to mean?
[Tux] neither do I :) 08:51
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 ...
weird: not in the source code at all 08:54
ignore that 08:55
lizmat ah, just remove the 1
indeed has no function there
[Tux] removed and pushed 08:57
09:13 Voldenet left 10:23 Voldenet joined
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»»
lizmat c: HEAD use v6.*; my @a := [1,[2,[3,4]]]; @a[||(1,)] := 42; dd @a
committable6 lizmat, ¦HEAD(25984bb): «[1, 42]␤»
lizmat meh
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:34
lizmat if you're talking about 9 ^.. 7 , then we would need to build the check into infix:<^..> 10:36
and I guess then only if they are literal values
so maybe this needs to be a worry in the grammar ?
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:38
lizmat Again, you're talking literal values: the constructor doesn't see that 10:39
and disallowing that will most likely break existing code that depends on being able to create an empty Range with such endpoints 10:40
so I think a worry in the grammar is the best way forward when literal values are specified 10:41
the worry could be something like: reverse Ranges are not supported, did you mean to use the sequence operator: ...
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:42
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:43
lizmat yeah, because most likely the user intended to use ... or wasn't aware that decreasing ranges aren't a thing 10:44
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. 10:47
lizmat m: my @a = 1; @a[0;0] = 42 # meh 11:37
camelia Cannot modify an immutable Int (1)
in block <unit> at <tmp> line 1
Geth rakudo/lizmat-78: aea709da78 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Fix Any:D.AT-POS() candidate

It wasn't returning a container if called on a container. Also remove the "is raw" trait on an AT-POS candidate that will never return anyway.		 11:53
rakudo: lizmat++ created pull request #6853:
Fix Any:D.AT-POS() candidate
rakudo/lizmat-79: ebcb78ebb3 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Make sure dd() properly reports on caller's scope

Looks like legacy actually removed the frame of the "else" in which the reporting lived: RakuAST needed an extra level.
Fix this more generally by making sure that if no arguments are specified, the reporting is done from the sub's scope itself.
This fixes the issue for core's built with legacy, as well as with RakuAST. And if in the future "else" scopes will also be optimized away, then this will continue to work properly.		 13:14
rakudo: lizmat++ created pull request #6854:
Make sure dd() properly reports on caller's scope		 13:15
rakudo/main: cfb221c3e2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Any.rakumod
Fix Any:D.AT-POS() candidate (#6853)

It wasn't returning a container if called on a container. Also remove the "is raw" trait on an AT-POS candidate that will never return anyway.		 13:16
roast: bed6022ba0 | (Elizabeth Mattijsen)++ | S09-multidim/XX-POS-on-undimensioned.t
Add test for github.com/rakudo/rakudo/commit/cfb221c3e2
 13:28
[Coke] Release tentatively scheduled for a week from Saturday. No hiccups on any commits so far in blin 13:33
releasable6: next
releasable6 [Coke], Next release in ≈9 days and ≈5 hours. There are no known blockers. 46 out of 184 commits logged
[Coke], Details: gist.github.com/f1898250f4bce4b8bd...cb23299bc1
[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:39
(I guess that tag is just blocker, actually) 13:40
Geth rakudo/main: 7373bf69e8 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Any.rakumod
Make sure dd() properly reports on caller's scope (#6854)

Looks like legacy actually removed the frame of the "else" in which the reporting lived: RakuAST needed an extra level.
Fix this more generally by making sure that if no arguments are specified, the reporting is done from the sub's scope itself.
This fixes the issue for core's built with legacy, as well as with RakuAST. And if in the future "else" scopes will also be optimized away, then this will continue to work properly.		 15:48
rakudo/lizmat-64: 48aed24ced | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
Oops, forgot one "int"
 16:26
rakudo/main: a3e3686389 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
RakuAST: create ::IfUnless base class (#6831)

The handling of RakuAST::StatementModifier::If and ::Unless differ only in the nqp op that generates the QAST. Instead ::Unless doing a cat-license of ::If, create a base class ::IfUnless referring to a method that provides the op-name, and make ::If and ::Unless provide the correct op name.
This also allows some conditions /base and /var-loweing to be simplified.		 16:29
rakudo/main: 4872dd8950 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod
RakuAST: add base class RakuAST::MetaInfix::CrossZip (#6834)

The logic of RakuAST::MetaInfix::Cross and RakuAST::MetaInfix::Zip are identical, except for three values:
  - action ('cross with' | 'zip with')
  - metaop ('X' | 'Z')
... (11 more lines)		 16:30
16:38 finanalyst joined
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 ?
ab5tract well I managed it with whatevercodes 16:48
lizmat ok, maybe I'm not understanding ?
ab5tract I'm pretty sure we can now surface where clauses in the usage handler
so that you can actually see what the rejection criteria is 16:49
lizmat well, if you can, more power to you! :-) 16:50
Geth rakudo/main: 8d60a82737 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 4 files
RakuAST: nqp::objprimspec can handle nqp::null (#6832)

So there is no need to extra guard against this eventuality.
Also slightly re-arrange some if's into ternaries
lizmat m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^500000; say now - ENTER now 16:54
camelia 0.296980531
lizmat m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||<1 1 1>] for ^500000; say now - ENTER now
camelia 0.276994147 16:55
lizmat m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^1000000; say now - ENTER now
camelia 0.54141459
lizmat m: use v6.*; my @a := [1, [2, [3,4]]]; @a[||<1 1 1>] for ^1000000; say now - ENTER now
camelia 0.536706294
lizmat argh 16:56
c: HEAD use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^1000000; say now - ENTER now
committable6 lizmat, ¦HEAD(8d60a82): «No build for this commit»
lizmat c: HEAD~1 use v6.*; my @a := [1, [2, [3,4]]]; @a[||1,1,1] for ^1000000; say now - ENTER now
committable6 lizmat, ¦HEAD~1: «1.666141178␤»
lizmat c: HEAD~1 use v6.*; my @a := [1, [2, [3,4]]]; @a[||<1 1 1>] for ^1000000; say now - ENTER now
committable6 lizmat, ¦HEAD~1: «1.237835858␤»
lizmat so why is a list of allomorphs faster than a list of ints ? 16:57
it's because currently <1 1 1> is qasted as a WVal, and 1,1,1 is QASTed as infix:<,>(1,1,1) 16:58
Geth rakudo/main: fba5df0890 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
RakuAST: make several lookup tables compile-time (#6836)

So that they don't need to be initialized every time they are about to be accessed.		 16:59
rakudo/main: 72076fa94e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod
RakuAST: replace variable by literal (#6837)

This variable was only initialized to zero, and then used without being referenced or mutated anywhere else.		 17:00
17:11 finanalyst left
ab5tract but both of those look correct to me 17:12
Geth rakudo/lizmat-59: 48 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++, (Will Coleda)++
review: github.com/rakudo/rakudo/compare/1...63a8ac63c7		 17:52
lizmat they are both correct, but one is significantly faster than the other 17:53
if infix:<,> is the core infix:<,> at compile time, then (1,1,1) can also be QASTed as a WVal 17:54
19:28 hankache joined 19:58 Pixi` joined 20:01 Pixi left
Geth rakudo/lizmat-80: 35fb7a4fdf | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod
Re-imagine ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE

  - no return statements
  - re-arranged conditions so short-circuiting can happen earler
  - assuming it will usually work, use ifnull for condition in binding		 20:05
rakudo: lizmat++ created pull request #6856:
Re-imagine ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE
rakudo/lizmat-64: 14 commits pushed by (Elizabeth Mattijsen)++, (Will Coleda)++
review: github.com/rakudo/rakudo/compare/4...74a635ef2e		 20:07
rakudo/main: a7cbac9ecc | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | tools/build/monitor-process.pl
Fix typo in argument handling (#6850)
 20:08
rakudo/main: db8e2b4179 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/variable-declaration.rakumod
RakuAST: simplify missing initializer test (#6838)

No need to create intermediate variables		 20:09
rakudo/main: d9a5d7dd86 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/resolver.rakumod
RakuAST: streamline ::Resolver::(EVAL|Compile) (#6842)

Specifically the .current-scope and .outer.scope methods, as these are pretty hot during compilation, and use atpos(..,i) vs ...[i] is about 2x as fast.		 20:13
rakudo/main: 1ca0a10077 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/resolver.rakumod
RakuAST: streamline ::Resolver::(EVAL|Compile).find-scope-property (#6843)

Another hot method during compilation, rewritten to use atpos and no return statements.		 20:14
rakudo/main: 8bc8f978ba | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod
RakuAST: optimize ::Infix.IMPL-APPLY-SINK-TO-OPERANDS (#6840)

In this relatively hot piece of code, replace for loops by native nqp::while and use nqp::atpos instead of postcircumfix []. For reference, an nqp::while loop + nqp::atpos is about 2x as fast as a for loop in nqp. That's because the iterator overhead is pretty big in nqp. And using nqp ops also creates smaller bytecode so more chance of inlining.		 20:18
rakudo/main: bb691c098e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/expressions.rakumod
RakuAST: optimize ::Assignment.IMPL-APPLY-SINK-TO-OPERANDS (#6841)

In this relatively hot piece of code, replace for loops by native nqp::while and use nqp::atpos instead of postcircumfix [].		 20:19
23:27 coleman left, apogee_ntv left 23:44 coleman joined, apogee_ntv joined 23:48 coleman left, apogee_ntv left, coleman joined 23:49 apogee_ntv 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!