[00:02] *** librasteve_ left
[00:36] <Geth> ¦ rakudo: ugexe++ created pull request #6273: RakuAST: don't drop a declaration when collapsing a constant conditional

[00:36] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6273

[01:10] <Geth> ¦ rakudo: ugexe++ created pull request #6274: Accept a Mu lhs and rhs in the test-assign metaops

[01:10] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6274

[02:35] <Geth> ¦ rakudo: ugexe++ created pull request #6275: RakuAST: route smartmatch through the smartmatch dispatcher

[02:35] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6275

[02:35] <Geth> ¦ rakudo: ugexe++ created pull request #6276: RakuAST: don't run a parameter type's ACCEPTS when checking multi signatures

[02:35] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6276

[03:59] <Geth> ¦ rakudo: ugexe++ created pull request #6277: RakuAST: don't redeclare a special variable bound in a sub signature

[03:59] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6277

[05:01] *** hurufu joined
[05:38] *** finanalyst__ joined
[05:38] *** finanalyst_ left
[09:33] *** Guest55 joined
[10:12] *** hurufu left
[10:18] *** hurufu joined
[11:20] * [Coke] makes a very laggy connectin to IRC from mid-air.

[11:21] <lizmat> .oO( 8 miles high...  :-)

[11:24] * [Coke] hurls https://github.com/rakudo/rakudo/issues/6278

[11:24] <[Coke]> 5 different commits to look at.

[11:24] <lizmat> the App::RaCoCo is interesting, as it references a doc change  :-)

[11:25] <[Coke]> one of them is mine!

[11:25] *** guifa_ joined
[11:25] <[Coke]> note that the doc one also includes one exception text change.

[11:26] <[Coke]> yup. they are checking the text of the message, not the type

[11:27] <[Coke]> bug in module, should always prefer exception type if available.

[11:27] <lizmat> yup

[11:27] *** guifa left
[11:27] <[Coke]> .seen atroxaper

[11:27] <tellable6> [Coke], I saw atroxaper 2023-01-16T03:08:56Z in #raku: <atroxaper> rf Voldenet: Thank you :)

[11:27] <lizmat> the "vars" also looks like it is an iffy test

[11:28] <[Coke]> I'll submit a PR for that one.

[11:28] <lizmat> ack

[11:28] <lizmat> ++[Coke] 

[11:28] <[Coke]> (the pre-compile one)

[11:32] <[Coke]> Ah, pre-compile is coming from the stderr of another process. will update the regex instead. :|

[11:33] *** Guest55 left
[11:35] <lizmat> bisectable6: old=2026.05 CATCH { .resume }; "foo".EVAL

[11:35] <bisectable6> lizmat, Bisecting by output (old=2026.05 new=9b162bc) because on both starting points the exit code is 1

[11:35] <bisectable6> lizmat, bisect log: https://gist.github.com/62965646d4ebebbba86512cfb264a6c9

[11:35] <bisectable6> lizmat, (2026-06-10) https://github.com/rakudo/rakudo/commit/25200ba632b23a7d471bef171c09b1ebfb8f8ce8

[11:38] <lizmat> the "vars" one is fixable

[11:38] <lizmat> in the module

[11:38] <lizmat> will do that later today

[11:42] <[Coke]> PR submitted on racoco

[11:43] <[Coke]> I will be away next weekend, but should be able to kick off a second blin run (several commits to still process)

[11:48] <lizmat> cool!

[11:52] <[Coke]> ugexe: looks like ASTQuery is testing what the resulting AST nodes look like, and then fails a test because the optimization happened.

[11:53] <[Coke]> bug in the test

[11:59] <[Coke]> .seen fco

[11:59] <tellable6> [Coke], I haven't seen fco around, did you mean cog?

[11:59] <lizmat> .seen Smokemachine

[11:59] <[Coke]> -> afk

[11:59] <tellable6> lizmat, I saw Smokemachine 2026-06-04T01:26:50Z in #raku: <SmokeMachine> japhb: yes, that’s Selkie::UI…

[11:59] <lizmat> [Coke] ^^

[12:00] <SmokeMachine> FCO here! What have I done wrong?

[12:01] <lizmat> ASTQuery needs its tests adapted because there are some simple optimizations in RakuAST now

[12:01] <SmokeMachine> I’ll try to take a look at it after work

[12:01] <lizmat> ++SmokeMachine 

[12:02] <lizmat> https://github.com/rakudo/rakudo/issues/6278

[14:03] *** librasteve_ joined
[14:38] <disbot4> <librasteve> please do help us to raise Raku awareness by going here https://news.ycombinator.com/item?id=48541940 in the next few minutes and commenting your thoughts (the metric is comments per minute)

[15:22] *** hurufu left
[15:22] *** hurufu1 joined
[15:24] *** hurufu1 is now known as hurufu

[16:13] <SmokeMachine> how can I see the error? I tried building raku main and run the tests, but no errors...

[16:14] <SmokeMachine> [Coke], lizmat ☝️?

[16:15] <[Coke]> are you including 801a103

[16:16] <[Coke]>  that gives me the error here.

[16:17] <SmokeMachine> I'm trying to `rakubrew build moar 801a103` and try again

[16:18] <[Coke]> I tried it with 2026.05, worked fine, and moar-e93a9dfac1, and it failed.

[16:19] <[Coke]> (and the bisect took it to 801a103)

[16:20] <[Coke]> depending on why those tests, might want to match the optimized version, or (can we?) disable the optimizer to get original results, etc.

[16:20] <SmokeMachine> https://www.irccloud.com/pastebin/NY7pHgAU/

[16:21] <SmokeMachine> I'm trying with moar-e93a9dfac1

[16:26] <[Coke]> are you testing the published version?

[16:26] <[Coke]> or HEAD?

[16:26] <[Coke]> try "zef look ASTQuery" and when that opens "zef test ."

[16:27] <SmokeMachine> I think mi6 is not using the right raku version...

[16:27] <[Coke]> yah, I get the same error in your HEAD with 'zef test .'

[16:28] <[Coke]> did you install mi6 under this version of raku in rakubrew?

[16:29] <[Coke]> what does `which mi6` say?

[16:34] <SmokeMachine> https://www.irccloud.com/pastebin/1nvTSKTY/

[16:35] <SmokeMachine> I have another raku installed here... that was the problem... I'm trying to fix the test now

[16:37] <[Coke]> \o/

[16:45] <ugexe> i wonder if an .AST(:optimize<off>) would make sense. someone would have to put some thought into it

[17:14] <SmokeMachine> I think that's breaking the usability of the module... :(

[17:14] <lizmat> wasn't this just about the test expecting the wrong thing ?

[17:19] <SmokeMachine> no, it was expecting the correct thing before, but now it's not. For example `say 1 + 2`, it now is equivalent to `say 3`... I really think the AST should be related to what is written, and any optimizationshould come in a future step...

[17:19] <lizmat> well, the future step is here  :-)

[17:20] <SmokeMachine> I mean future step of the compiler...

[17:20] <SmokeMachine> https://www.irccloud.com/pastebin/rzROGqT4/

[17:22] <librasteve_> https://rakudoweekly.blog/2026/06/15/2026-24-the-raku-foundation/

[17:22] <lizmat> librasteve_++

[17:24] <SmokeMachine> if the AST is going to "be different from the code", that module kinda looses its value, no?

[17:28] <SmokeMachine> I don't really know what to do... :(

[17:30] <ugexe> disable optimizations for your test?

[17:31] <ugexe> i don't see how to have a separate optimization stage without serializing the resolver to pass between stages, which is something that needs to be done

[17:31] <SmokeMachine> but that would work only for the tests... the usage would still be kinda blah...

[17:32] <ugexe> "something that needs to be done" = avoiding serializing the resolver

[17:32] <SmokeMachine> how do I disable optimizations for the test?

[17:32] <[Coke]> I'm not sure what the purpose of those ASTQuery tests are - seems like if we want the AST to be a certain way for certain code, that's a rakudo test, not a a module test (and it's an internal detail we can change)

[17:33] <SmokeMachine> the other option would be removing the module from the ecosystem, right? (and I'm not sure if that's an option...)

[17:34] <ugexe> it can be removed from something Blin scans at least

[17:34] <[Coke]> There is no way currently to remove a module. I think the suggested option is to release a version that then refuses to install, maybe.

[17:34] <[Coke]> (blin) right, that's easy

[17:34] <SmokeMachine> [Coke]: I'm not saying it affects the purpose of the tests, but the purpose of the module itself.

[17:34] <[Coke]> I mean, for now, I'm not considering this a blocker for the release.

[17:34] <[Coke]> SmokeMachine: I only looked at the test, one sec.

[17:35] <[Coke]> I mean, you can still match against the AST...

[17:35] <[Coke]> it's just that the AST may be simpler than expected.

[17:35] <ugexe> would the theoretical .AST(:optimize<off>) or whatever be sufficient?

[17:36] <SmokeMachine> I'm going to change the tests, but the module now is much less useful than it was before...

[17:37] <SmokeMachine> not simpler, different, the example `say 1 + 2`, search for `2` will never work...

[17:39] <SmokeMachine> ugexe: I suppose so

[17:40] <SmokeMachine> but it would not make sense to use the module if it would make your code slower...

[17:45] <[Coke]> I think being able to dump/search the AST is helpful - the problem is expecting it to be a 1:1 to the code. I would "just" add caveats that because of the optimizer, you may find that some nodes you might expect will be skipped by the compiler.

[17:46] <ugexe> well, it wouldnt be any slower than it currently is

[17:46] <[Coke]> wonder if the optimizer could optimize slightly more of 'my $a =3; say $a-1+2*5-123'

[17:47] <[Coke]> (it reduces it to $a-1+10-123)

[17:47] * [Coke] puts a pin in that to look at maybe on the plane on the way back

[17:50] <ugexe> ((($a - 1) + (2*5)) - 123)

[17:52] <ugexe> there is probably a subset of $a that it could be optimized more

[17:57] <[Coke]> yah, -1+2*5-123+$a collapses everything

[17:57] <ugexe> m: my Num ($a, $b, $c) = 1e0, 1e20, -1e20; say ($a + $b) + $c == $a + ($b + $c);

[17:57] <camelia> rakudo-moar 9b162bcf7: OUTPUT: «False␤»

[17:59] <ugexe> so we have to know the associativity for $a type's various operators

[18:00] <ugexe> probably why the legacy frontend does optimize it either

[18:00] <ugexe> doesnt^

[18:10] <SmokeMachine> I just release a new version that the tests should be passing...