Geth rakudo: ugexe++ created pull request #6658:
Apply :ratchet to an atom followed by sigspace whitespace		 00:52
ugexe [Coke]: any way you could do a blin run on github.com/rakudo/rakudo/pull/6658 ? I'm trying to see the fallout (as there is at least one: ASN::Grammar) to determine if its something we can even change at this point 00:53
[Coke] I think we need to copy your branch to one on rakudo/rakudo, should be easy 01:17
on it 01:18
ugexe thanks! 01:20
Geth rakudo/ugexe/rakuast-sigspace-ratchet: da2a52539d | (Nick Logan)++ | 4 files
Ratchet the atom under trailing sigspace

In a ratchet regex the whitespace that sigspace inserts after an atom was attached inside the node the enclosing position ratchets, so the ratchet landed on a concat, which the regex compiler ignores. A quantifier, alternation, subrule call or capture group followed by whitespace in a rule or an rx:r:s regex therefore backtracked as if there were no ratchet: ... (24 more lines)		 01:21
rakudo/ugexe/rakuast-sigspace-ratchet: b180d6078d | (Nick Logan)++ | t/02-rakudo/ltm-before-assertion.t
Backtrack explicitly in the LTM before-assertion test grammar

The lookahead in the test grammar's infix chain rule matched `.+` and then an operator, with rule whitespace in between. A rule ratchets that quantifier, so once it has taken the rest of the input it cannot give the operator back, and the lookahead only succeeded while the whitespace after the quantifier shielded it from the ratchet.
This backtracks with `.+!` instead, which stays declarative for the LTM prefix the test is about and matches under the ratchet.
[Coke] c: b180d6078d e.say # when this works I can blin run
committable6 [Coke], ¦b180d60: «Cannot find this revision (did you mean “7fb098d”?)»
[Coke] started 01:37
did it from 2026.08 so we also get the last few commits that weren't in the last run
⏳ 1250 out of 2520 modules processed (49.6%) 03:00
Geth rakudo: ugexe++ created pull request #6659:
RakuAST: fix a batch of deparse holes found by round tripping raku code		 03:47
04:46 kurahaupo joined 06:48 kurahaupo left 07:28 lizmat joined 07:53 kurahaupo joined 08:12 lizmat left 10:44 kurahaupo left 10:56 kurahaupo joined 13:05 ilogger2 left 13:17 ilogger2 joined 13:18 camelia left, camelia joined 13:19 nine left 13:20 nine joined 13:27 kurahaupo left 13:45 kjp left, rba left, disbot left 13:50 lizmat joined 13:51 kjp joined, rba joined, disbot joined 13:52 disbot left, disbot3 joined 13:53 disbot3 is now known as disbot
lizmat . 14:00
lizmat waves from Prague
[Coke] github.com/coke/raku-blin-release-results is currently showing the redo run - 7 failures, include the one needle 14:03
lizmat [Coke]: I hope to have some time tomorrow, but it could well be that I won't be able to fix Compile::Needle before Friday 14:04
[Coke] Yup, that's fine.
lizmat cool... ... now going back to being a tourist& 14:05
14:05 lizmat left
ab5tract waves to lizmat in Prague (if you are reading this Liz shut the laptop lid!) 14:28
Do I recall some conversation related to ridding ourselves of P5Regex and QP5Regex? 14:29
Geth rakudo/main: 17 commits pushed by (Nick Logan)++
review: github.com/rakudo/rakudo/compare/b...26c8856aca		 14:54
rakudo: ugexe++ created pull request #6660:
RakuAST: fix a second batch of deparse holes found by round tripping modules		 15:03
[Coke] releasable6: next 15:06
releasable6 [Coke], Next release in ≈18 days and ≈3 hours. There are no known blockers. 174 out of 174 commits logged
ugexe "Should we make breaking changes to the regex engine along with RakuAST?" - github.com/Raku/problem-solving/issues/528 17:31
[Coke] I think if we gated it at 6.e, that'd be a no brainer. The question is, what if we do it, then make RAKUAST the default while still on 6.d, yes 18:10
?
ugexe the problem is no one puts `use v6.d` in their modules, so when we switch to 6.e those modules would still be opt-ing into the new behavior that would break them 18:19
and there is no way to warn them ahead of time about it
which is basically the same thing as gating it
so then why gate it at all 18:20
with most of the other gated changes people's code will break very obviously
although to be fair i guess we found those 6 modules that would break, which did break pretty obviously with the new behavior 18:23
the other thing is one of the changes is in nqp, so it would apply to legacy. the main reason i name rakuast at all is because we are breaking other things in rakuast so the release of rakuast already will have the expectation of some breakage 18:28
m: sub foo(*@_, Int :$bar) { say $bar.WHAT }; foo(bar => "abc"); # for example this errors under RakuAST, and we don't bother revision gating the previous obviously broken behavior 18:30
camelia (Str)
ab5tract So this is a bit of a brain stretch on my part, but should we consider having no `use v6.` statement at all would default to the previous language release? 18:53
s/should/could/ 18:54
ugexe that just kicks the can down the road for one release 18:55
ab5tract true, but it does give more breathing room and less (annoying, imo) noise about "this release breaks my unbounded-to-a-release code" 18:57
so that at least the bug reports that arrive after pressing 6.e are actually about 6.e
ugexe i dont think the people this would affect are going to catch this any earlier than whenever the new behavior is forced on them 18:58
it is also kind of difficult to document these things. like how do you describe the change in LTM behavior of certain constructs in certain situations 18:59
ab5tract yeah, that's fair. I just really don't enjoy that part of the release cycle. 19:02
ugexe it would also be sort of unfortunate if all the new raku implementation have to encode this broken regex behavior for certain revisions and a different non broken regex behavior for others, as i kind of think they just would just skip the revision and implement the correct way
ab5tract Oof, I hadn't even thought of that. 19:03
ugexe Another way I think of when to revision gate is: would I feel ok enshrining the broken behavior in pre-6.e roast tests if it isn’t already enshrined there? 19:07
[Coke] if these were clearly bugs, I think we're allowed to fix bugs regardless of version. 19:12
(are they clearly bugs?)
19:15 finanalyst joined
ab5tract P5Regex isn't a bug but it isn't exactly something to keep around either 19:16
but in general I think you're pointing out a great rule of thumb 19:18
ugexe hard to say what is clearly a bug in this case. i lean towards yes in the sense that if someone read the speculations they would have wrote something slightly different or files a bug report, and that the roast doesn't encode the broken behaviors 19:23
ab5tract: did you see github.com/rakudo/rakudo/pull/6534 ? i assume that aligns with getting rid of P5Regex
the roasts technically allow p5 regex not to work as long as its a runtime failure: github.com/Raku/roast/blob/85a8790...0.t#L9-L12 19:24
my PR is a compile time error though (and it should be) so that check never gets to apply 19:25
m: say "a" ~~ m:XXX/a/; 19:26
camelia ===SORRY!=== Error while compiling <tmp>
Adverb XXX not allowed on m
at <tmp>:1
------> say "a" ~~ m:XXX/a/<HERE>;
ab5tract yeah, that would cover it, sans the relevant nqp cleanup of course 19:28
I hadn't seen that one yet, but it feels like its adoption is predicated on a 'yes' answer to the problem solving ticket 19:32
ugexe we already decided we aren't implementing p5 regex in rakuast, we just haven't decided what that actually looks like / means 19:33
ab5tract ah, ok. that's probably the discussion I was vaguely remembering 19:34
ugexe my biggest issue with having it is the question of "which version of p5 regex?", when do we update that, etc 19:36
the version implemented now is behind what current perl implements 19:37
inline::perl5 will work on rakuast so if someone really wants perl regex they can just use that 19:39
20:21 lizmat joined 21:25 finanalyst left 22:04 lizmat left
Geth rakudo/main: 35 commits pushed by (Nick Logan)++
review: github.com/rakudo/rakudo/compare/a...7db968c7b0		 22:15
rakudo: ugexe++ created pull request #6661:
RakuAST: fix a third batch of deparse holes found by round tripping raku code		 22:22
ugexe lots of commits, but they are mostly 1-5 line changes (not including tests) 22:23
japhb Doesn't make them any less valuable. ;-) 22:55
23:12 kurahaupo 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!