[00:45] <Voldenet> ugexe: obviously R should start from the tail as it used to previously, so `[R_] …` should be equivalent to `[_] reverse …`

[00:49] <Voldenet> docs also say "Associativity of operands is reversed as well."

[00:54] <Voldenet> I'm pretty sure that the result of `R,` should be flattened too, it could maybe make sense to have `multi infix:<,>(*@a) { … }`

[01:07] <Voldenet> otoh, reduce is defined as "processing list from left to right"

[01:07] <Voldenet> no strings attached, `R-` op is applied later, so `((1 R- 2) R- 3)` seems correct

[01:08] <Voldenet> reduce doesn't say anything about operator's associativity

[01:08] <Voldenet> …haha, okay, I read further into docs and

[01:08] <Voldenet> `If &with is the code object of an operator, its inherent identity value and associativity is respected`

[01:10] <Voldenet> so in short `say [R-] 1, 2, 3` should be equivalent to `say 1 R- 2 R- 3`

[01:13] <Voldenet> it gets really confusing fast and apparently both current implementation and rakuast impl is wrong

[01:19] <Voldenet> nah, old implementation is right, rakuast is wrong

[01:20] <Voldenet> m: say qqx/RAKUDO_RAKUAST=1 raku -e 'say 2 R- 3 R- 4; say [R-] 2, 3, 4'/

[01:21] <evalable6> Voldenet, rakudo-moar 6f0f1f5a8: OUTPUT: «-1␤3␤␤»

[01:23] <Voldenet> m: say qqx/RAKUDO_RAKUAST= raku -e 'say 2 R- 3 R- 4; say [R-] 2, 3, 4'/

[01:23] <evalable6> Voldenet, rakudo-moar 6f0f1f5a8: OUTPUT: «-1␤-1␤␤»

[01:24] <Voldenet> apparently rakuast has reduce impl that assumes left-assoc of the operator, which R reverses

[01:26] <Voldenet> m: say qqx/RAKUDO_RAKUAST=1 raku -e 'say 2 R** 3 R** 4; say [R**] 2, 3, 4'/ # this correctly uses right associativity, which in this case is left :>

[01:26] <evalable6> Voldenet, rakudo-moar 6f0f1f5a8: OUTPUT: «262144␤262144␤␤»

[01:31] <Voldenet> m: say qqx/RAKUDO_RAKUAST=1 raku -e 'say 4 ** (3 ** 2); say [**] 4, 3, 2'/ # apparently reduce metaop is able to understand right-assoc just fine, so the bug is just in the R metaop

[01:31] <evalable6> Voldenet, rakudo-moar 6f0f1f5a8: OUTPUT: «262144␤262144␤␤»

[01:33] *** MasterDuke joined
[01:42] <Voldenet> I'm naively thinking that simply replacing `[R_]` with `[_] reverse` could work in any case, but I have no way to prove it

[02:10] *** MasterDuke left
[04:16] <Geth> ¦ rakudo: ugexe++ created pull request #6201: RakuAST: emit proper SORRY exceptions for invalid feed-operator stages

[04:16] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6201

[10:06] *** Pixi` joined
[10:08] *** Pixi left
[10:24] *** donaldh joined
[10:36] *** librasteve_ left
[10:42] *** kurahaupo left
[11:00] <releasable6> Next release in ≈3 days and ≈7 hours. 1 blocker. Please log your changes in the ChangeLog: https://github.com/rakudo/rakudo/wiki/ChangeLog-Draft

[11:12] *** kurahaupo joined
[11:31] *** kurahaupo left
[11:31] *** donaldh left
[11:31] *** donaldh joined
[11:39] *** kurahaupo joined
[13:10] *** hurufu joined
[14:38] *** kjp left
[14:38] *** kjp joined
[14:39] *** hurufu left
[15:31] <[Coke]> https://gist.github.com/coke/97d0aafddd5adfa736386d9ce86eb7d5

[15:31] <[Coke]> ^^ 3 commits mentioned over 6 packages - the first one is the merge commit, so maybe just a flapper.

[15:31] <[Coke]> er, a release merge commit

[15:44] <lizmat> ok, both by me  :-(

[15:54] <[Coke]> I understand we have one more localized bug fix that wants in, and then maybe fixing these issues before Saturday?

[15:56] <lizmat> yes, the Gzz and Clifford ones I already left issues for

[15:56] <lizmat> so are not fixable in core

[15:56] <[Coke]> please nothing too big going in before then.

[15:57] <lizmat> fixing %g format in 6.e sprintf is the only thing I'm still working on

[15:57] <[Coke]> I see no issues on Gzz-Text-Utils

[15:57] <lizmat> it's borked at the moment, and blin didn't see that, so I don't worry too much about that (or its fix)

[15:58] <lizmat> the problem with Gzz... is one of the dependencies: Gzz::Prompt    I left the issue there

[15:58] <[Coke]> ah

[15:58] <[Coke]> ... interesting that the dependency didn't show up in this list?

[15:58] <lizmat> not sure why blin didn't catch that, indeed

[15:59] <lizmat> looking at Curry atm

[16:00] <[Coke]> ah, I probably should have opened an actual ticket, just threw it in a gist to get it out there asap

[16:00] <[Coke]> one sec

[16:01] <[Coke]> added to https://github.com/rakudo/rakudo/issues/6168

[16:04] <lizmat> aah... indeed.   now I remember...  seems codeberg is up now, so I will make an issue for Curry there now

[16:15] <lizmat> hmm...wonder why we didn't see the JSON::RPC one before

[16:15] <lizmat> seems like the synthetic code has trouble finding the URI symbol

[16:19] *** Pixi` is now known as Pixi

[16:41] <lizmat> hmm... ok, looks like the JSON::RPC is actually pointing to a real issue...

[16:41] <lizmat> but still not understanding why we didn't see this before

[16:42] <ugexe> probably some follow up rakuast work

[16:43] <ugexe> since assuming is exposing rakuast changes

[16:43] <ugexe> anywho don't worry about it, i'll fix it after work

[16:43] <lizmat> golfed to: use URI; my sub a(URI :$uri) { dd }; my &b = &a.assuming(:uri(URI.new))

[16:44] <lizmat> the problem is the URI constraint on the argument in sub A

[16:44] <lizmat> it generates:

[16:44] <lizmat> RakuAST::Parameter.new(

[16:44] <lizmat>         type    => RakuAST::Type::Simple.new(

[16:44] <lizmat>           RakuAST::Name.from-identifier("URI")

[16:44] <lizmat>         ),

[16:44] <lizmat> should that be something other than Type::Simple ?

[16:45] <ugexe> my hunch will be the context being passed to eval

[16:46] <ugexe> s/hunch/wild guess/

[16:46] <lizmat> s/.URI/Int/  and everything's ok, so it really looks like a context issue

[16:48] <lizmat> context is CALLER::LEXICAL::  (the default)

[16:48] <lizmat> maybe assuming needs its CALLER::LEXICAL:: context

[16:50] <lizmat> $ast.EVAL(:context(CALLER::LEXICAL::))

[16:50] <lizmat> now fails with:

[16:51] <lizmat> ===SORRY!=== Error while compiling:

[16:51] <lizmat> 'self' used where no object is available

[16:52] <ugexe> yeah, that isnt sufficient

[16:53] <ugexe> https://github.com/ugexe/rakudo/commit/cdb32ba2eb84e98ac3fa497caa95544c8892b049

[16:53] <ugexe> i tossed the problem to the clanker and thats what it came up with. i haven't vetted it at all though and won't have time for another 5ish hours

[16:54] <lizmat> ack, thanks, looks like that will work

[16:55] <ugexe> lol... `END { run(<rm -rf>, $tmp.Str) if $tmp.defined && $tmp.e }`

[17:04] <lizmat> the proposed fix fixes JSON::RPC, but breaks some spectest

[17:14] <Geth> ¦ rakudo/lizmat-5: 447caa85c7 | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod

[17:14] <Geth> ¦ rakudo/lizmat-5: Fix for .assuming not seeing imported symbols

[17:14] <Geth> ¦ rakudo/lizmat-5: 

[17:14] <Geth> ¦ rakudo/lizmat-5: Adaptation from ugexe++ https://github.com/ugexe/rakudo/commit/cdb32ba2eb84e98ac3fa497caa95544c8892b049

[17:14] <Geth> ¦ rakudo/lizmat-5: 

[17:14] <Geth> ¦ rakudo/lizmat-5: Differences: also add support for a RAKUDO_ASSUMING_DEBUG environment

[17:14] <Geth> ¦ rakudo/lizmat-5: variable, and make the actual EVAL calling code a bit DRYer.  And no

[17:14] <Geth> ¦ rakudo/lizmat-5: test yet.

[17:14] <Geth> ¦ rakudo/lizmat-5: review: https://github.com/rakudo/rakudo/commit/447caa85c7

[17:18] <ugexe> why did you remove the .EVAL

[17:18] <ugexe> vs RakuAST::PointyBlock.new(|%args).EVAL(:$context)

[17:19] <lizmat> the EVAL is at the end

[17:19] <lizmat> so we can get some debug info inbetween

[17:25] <lizmat> m: class A { our method f(:$x) { } }; my &g = &A::f.assuming(my $a = A.new)

[17:25] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «»

[17:26] <lizmat> this is broken wth https://github.com/rakudo/rakudo/commit/447caa85c7

[17:26] <lizmat> m: class A { our method f(:$x) { } }; my &g = &A::f.assuming(A.new)

[17:26] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «»

[17:26] <lizmat> is *not* broken, so the `my $a =` is needed

[17:26] <lizmat> the error: This element has not been resolved. Type: RakuAST::Var::Lexical

[17:36] <lizmat> ah, I see the issue now: because the context has shifted to the caller, it doesn't see its own arguments anymore

[17:44] <lizmat> and that's needed in case the original sub had an "is raw" on it

[17:50] <lizmat> so what we need is a lookup chain that first does the lexical, and then the caller

[17:52] <lizmat> or somehow be able to specify more than one context

[17:53] <ugexe> Fix: in src/core.c/core_epilogue.rakumod:415-420: drop the @positionals[$i] indirection. Always embed the positional value via RakuAST::Literal.from-value(@positionals[$i]). The synthesised closure no longer needs @positionals to resolve in any scope.

[17:54] * lizmat tries

[17:55] <lizmat> but that won't work

[17:56] <ugexe> i would be surprised if it didn't work

[17:57] <lizmat> m: sub a($a is raw) { dd $a }; my $b = 42; my &c = &a.assuming($b); c; $b = 666; c

[17:57] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «$b = 42␤$b = 666␤»

[17:57] <lizmat> it breaks that ^^

[17:57] <lizmat> I guess you didn't know you could do that with .assuming

[18:00] <ugexe> 🤔

[18:00] <lizmat> I remember being very surprised by that  :-)

[18:31] <lizmat> I guess we need a way to enshrine the container into the AST

[18:47] <lizmat> something with RakuAST::ContainerCreator ?

[19:28] *** ShimmerFairy left
[19:30] *** ShimmerFairy joined
[19:53] *** ShimmerFairy left
[19:53] *** kurahaupo left
[19:53] *** Pixi left
[20:02] *** kurahaupo joined
[21:00] <lizmat> bisectable6: old=2026.04 sub a($a is raw) { dd $a }; my $b = 42; my &c = &a.assuming($b); c; $b = 666; c

[21:00] <bisectable6> lizmat, On both starting points (old=2026.04 new=6f0f1f5) the exit code is 0 and the output is identical as well

[21:00] <bisectable6> lizmat, Output on both points: «$b = 42␤$b = 666␤»

[21:00] <lizmat> bisectable6: old=2026.03 sub a($a is raw) { dd $a }; my $b = 42; my &c = &a.assuming($b); c; $b = 666; c

[21:00] <bisectable6> lizmat, On both starting points (old=2026.03 new=6f0f1f5) the exit code is 0 and the output is identical as well

[21:00] <bisectable6> lizmat, Output on both points: «$b = 42␤$b = 666␤»

[21:01] <lizmat> ugexe: turns out this behaviour is actually *not* enshrined in spec tests

[21:02] <lizmat> but it *is* a behaviour of the old implementation

[21:02] <ugexe> its not a big deal, i can probably fix it in like 15 minutes once im out of work

[21:06] <lizmat> ok, then I'll stop my research into this for now

[21:31] <[Coke]> releasable6: next

[21:31] <releasable6> [Coke], Next release in ≈2 days and ≈21 hours. 1 blocker. 87 out of 133 commits logged

[21:31] <releasable6> [Coke], Details: https://gist.github.com/949043d762f363e092574eb3fd743fbb

[21:32] <lizmat> [Coke]: looks like we also want to get https://github.com/MoarVM/MoarVM/pull/2006 in the release

[21:32] <[Coke]> lizmat: that sprintf fix still pending? if so please also create a blocker ticket for it.

[21:33] <lizmat> it's still pending... got distracted by the blin run :-)

[21:33] <[Coke]> I am very hesitant to merge a moar chang post blin

[21:33] <lizmat> it's preventing segfaults / buffer overflow

[21:34] <lizmat> it's been there for years, so in that sense we can wait... it's just that it's public now  :-(

[21:36] <[Coke]> ok.

[21:39] <ugexe> i'll fix pod::contents as well, i assume it is a similar issue

[21:43] <[Coke]> ugexe++ lizmat++

[22:07] *** ShimmerFairy joined
[22:16] *** vrurg_ joined
[22:20] *** vrurg left
[22:29] <Geth> ¦ nqp/main: f85683c67b | (Daniel Green)++ | tools/templates/MOAR_REVISION

[22:29] <Geth> ¦ nqp/main: Bump MoarVM for nqp::strtocodes() fix

[22:29] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/f85683c67b

[22:32] <Geth> ¦ rakudo/main: 07e674626c | (Daniel Green)++ | tools/templates/NQP_REVISION

[22:32] <Geth> ¦ rakudo/main: Bump NQP for nqp::strtocodes() fix

[22:32] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/07e674626c

[22:50] <Geth> ¦ rakudo: ugexe++ created pull request #6202: RakuAST: two Code.assuming bugs in synthesised closures

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

[22:51] <ugexe> that should fix JSON::RPC and Pod::Contents