01:16 hankache_ joined 01:20 hankache left 01:53 vrurg joined 01:56 vrurg_ left 02:49 hankache_ left
disbot <natt.e> Is this the right place? I found some things that changed after 2026.09 that I would consider bugs: raku say (1 RR[xx] *); # before: WhateverCode, after: Seq say comb sum 1000,2000: 2; # before: (30 00), after: Error $_ = "abc"; tr/a/x/; # after: Warning - "Useless use of tr/a/x/ in sink context" $a² or $a ** 2 # after: Much slower than $a * $a 08:39
lizmat reported as github.com/rakudo/rakudo/issues/6766 and github.com/rakudo/rakudo/issues/6767 09:07
disbot <natt.e> Thanks 09:08
lizmat bisectable6: old=2025.10 say [] ~~ (my $a = "b"); say $a 10:25
bisectable6 lizmat, On both starting points (old=2025.10 new=a61b582) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «False␤b␤»
lizmat c: 2026.09 say [] ~~ (my $a = "b"); say $a 10:26
committable6 lizmat, ¦2026.09: «True␤(Any)␤»
lizmat bisectable6: old=2026.09 say [] ~~ (my $a = "b"); say $a
bisectable6 lizmat, Bisecting by output (old=2026.09 new=a61b582) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/95f01bce3705af12e9...3893cb04e8
lizmat, (2026-09-26) github.com/rakudo/rakudo/commit/13...f81d56be1d
lizmat m: say Q|JSON::Fast:<foo:0.21>:auth<zef:timo>|.AST.statements.head.expression.name.colonpairs.head 12:15
camelia RakuAST::QuotedString.new(
processors => <words val>,
segments => (
RakuAST::StrLiteral.new("foo:0.21"),
)
)
lizmat ugexe: shouldn't that be a RakuAST::ColonPair::Value object ??
argh... pebkac 12:17
12:19 djinni` left 12:24 djinni` joined 12:49 [Tux] left 12:54 [Tux] joined
[Coke] blin clean through a0433344aa 13:05
linkable6 (2026-09-30) github.com/rakudo/rakudo/commit/a0433344aa RakuAST: only leave the scope for a heredoc body after a closing brace
[Coke] wonder if we should make whatever is building the rakudo-star dockerfile to also build coke/rakudo-docs-test:latest (and make sure they're all in a common, shared docker repo) 13:20
I should at least move the Dockerfile used for the docs testing into the docs repo. :| 13:21
Oh. "Welcome to Rakudo™ Star v2026.01." 13:24
that's rakudo-star:latest
... on my box. "versioning is hard..." 13:25
ok, the latest one is only v2026.06 13:35
Who is generating those? 13:36
(are we only doing it quarterly?)
14:38 camelia left 14:39 camelia joined 14:54 nine_ joined, nine left
Geth rakudo: ugexe++ created pull request #6769:
RakuAST: prime a Whatever under a meta-operator as any operator does
17:27
rakudo/main: 1782702146 | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
Make RakuAST::Name.is-identifier a bit faster

This method is getting called a *lot* during compilation. Make at least the bytecode smaller by replacing attribute accesses to
  $!parts by a lowered lexical $parts. No hard data, but it looks
like this takes off about 1% off of spectest wallclock.
17:29
rakudo/main: 629bd7e686 | (Elizabeth Mattijsen)++ | 2 files
Turn RakuAST::Name::Part into a role

Because it really is. This also allows simplification of the .raku fixups
17:48
ugexe we're just pushing everything straight to main? 17:49
lizmat ah, good point, sorry, future posts will be PRs again, sorry, got a little over excited :-) 17:52
ugexe im not so sure about that role change 17:59
first, there is apparently a regression
RakuAST::Name::Part::Expression.new(RakuAST::StrLiteral.new("foo")).raku
lizmat how did you find that? make test / spectest were clean for me? 18:01
ugexe the rule i followed on what to change to roles was to keep things as classes where the base of their kinds and no longer mixed in anywhere.
it can be intuited from the code/diff which is easy for an llm 18:02
lizmat iow, a CI test wouldn't have picked this up either ? 18:03
just for my understanding...
ugexe everything doesn't have a test
er, i havent tried to run ci or make test so i dont know
i just assume you did and that it just doesnt have a test 18:04
im pretty sure it should still be a class though
Geth rakudo/main: 8531d41b48 | (Elizabeth Mattijsen)++ | 2 files
Revert "Turn RakuAST::Name::Part into a role"

This reverts commit 629bd7e686cc8dfc529bdb3d923ac21188979708.
It was intuited that this broke:
   RakuAST::Name::Part::Expression.new(RakuAST::StrLiteral.new("foo")).raku
so reverting for now seems the appropriate thing to do
18:05
ugexe its also wrong that method is-empty() would now die, when if it were to stay a role it would need to be changed to a stub
lizmat I started to document RakuAST::Name;:Part, and it looked like a role to me, as creating a RakuAST::Name::Part object makes no sense?
so maybe it should be marked uninstantiable ? 18:07
ugexe a role would not stop that either, although you already know that. Node, Expression, Term, Statement Postfixish, (maybe others?) are all just as meaningless to instantiate and all allow it. I would probably document Name::Part as an abstract base class like those. If we want instantiation to fail I think the AST compiler would need to support repr("Uninstantiable") or whatever, and we'd want to 18:11
apply it to all the abstract bases at once
lizmat We could just give it a .new method that dies 18:12
ugexe i dunno if that is great for subclasses 18:14
lizmat I think we do that already in some cases
ugexe for name part specifically its probably fine, but as a general pattern i think you'd have to check the base type and call callsame() or something so subclassing works right 18:20
lizmat check
What's the difference between RakuAST::Name::Part::Empty and a RakuAST::Name::Part::Simple with an empty name ? 18:25
ugexe Empty is the :: at an edge of a name 18:28
Simple with "" is just a name part that happens to be blank 18:29
lizmat would a Simple with "" at the edge of a name also work?
or vice-versa, an Empty as a Simple with an empty name ? 18:30
you know what, I'll just make a PR for that :-) 18:32
ugexe no. if one type stood for both the compiler would have to guess which one it has from position and blankness instead of checking the type. a lone Empty would also claim to be a package lookup when it iss meant as a missing name 18:34
lizmat hmmm... so maybe ::Empty is a misleading name, and it should be EmptyEdge ? 18:35
that is, if Empty can only occur as the first or last part of a RakuAST::Name
ugexe yeah its have to be like EmptyEdge and not DoubleColon since the later might make people think it can be for non edges 18:39
Geth rakudo/lizmat-40: 83baac0d6a | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
Use a lookup table for ::Name::Part::Simple.is-pseudo-package

Instead of repeated comparisons
18:40
rakudo: lizmat++ created pull request #6770:
Use a lookup table for ::Name::Part::Simple.is-pseudo-package
18:41
lizmat m: say Q|MY::|.AST.statements.head.expression 18:58
camelia RakuAST::Term::Name.new(
RakuAST::Name.new(
RakuAST::Name::Part::Simple.new("MY"),
RakuAST::Name::Part::Empty
)
)
lizmat looks like Name::Part::Empty is both used as an instance and as a type object. Looks like we can always use it as a type object, afaics 18:59
ugexe I'd go the other way and always make an instance 19:03
just. because a type object generally reads as "nothing here" 19:05
lizmat but all the checks for ::Empty are nqp::istype checks 19:07
Geth rakudo/lizmat-41: e865825c29 | (Elizabeth Mattijsen)++ | 14 files
Change ::Name::Part::Empty to ::Name::Part::EmptyEdge

To more clearly indicate that these can only occur as the first or last part of a RakuAST::Name object
19:10
rakudo: lizmat++ created pull request #6771:
Change ::Name::Part::Empty to ::Name::Part::EmptyEdge
[Coke] Are we considering the class hierarchy that exists unchangeable except for new stuff? or are we saying rakuast is not *final* until 6.e?
ugexe you can't assume that just because that is how the core uses it that users wont want to e.g. .grep(*.defined) 19:11
[Coke] also, do we have to care about feedback from the other two compiler authors?
lizmat ugexe: ok, fair point, I'll make sure the .new gets added
[Coke]: re the other compiler authors: RakuAST at this stage is Rakudo only really, as there are no spectests for it 19:12
once there are, then we should consider them "final" fsvo "final"
is my opinion
anyway, these changes are fed by my working on the RakuAST documentation, and trying to explain what a class' function is 19:13
and finding inconsistencies that would be hard to explain
rather then explain them in documentation, I'd rather fix the inconsistencies 19:14
and make the naming more self-explaining
[Coke] ah, I thought there was talk about putting rakuAST into roast. 19:17
lizmat yes, there is! 19:18
but really just before we release 6.e
[Coke] ok. yes, *before it goes into roast*, do we need to reach out to them.
lizmat ash is aware of this already, not sure about tokuhirom 19:19
[Coke] (e.g. give them a chance to review the PR, or something)
lizmat pinged them in the PR 19:22
m: dd RakuAST::Name::Part::Simple.new("").is-empty 19:24
camelia ===SORRY!=== Error while compiling <tmp>
Use of RakuAST is experimental; please 'use experimental :rakuast;'
at <tmp>:1
------> dd RakuAST::Name::Part::<HERE>Simple.new("").is-empty
expecting any of:
argument list
term
lizmat m: use v6.*; dd RakuAST::Name::Part::Simple.new("").is-empty
camelia 1
lizmat m: use v6.*; dd RakuAST::Name::Part::Empty.new.is-empty
camelia Bool::True
Geth rakudo: ugexe++ created pull request #6772:
RakuAST: don't warn about a sunk tr/// or user-defined term
19:41
rakudo: ugexe++ created pull request #6773:
RakuAST: give an invocant colon to the listop it belongs to
19:42
rakudo/main: 31d48fde2d | (Nick Logan)++ (committed using GitHub Web editor) | 5 files
RakuAST: prime a Whatever under a meta-operator as any operator does (#6769)

Previously a meta-operator primed a Whatever or WhateverCode operand only as far as the operator it wraps would, apart from the negated and elementwise forms of a short-circuit. `xx`, `..`, `...`, `~~`, `∘`, `=`, the short-circuit operators, and a function infix take `*` or a WhateverCode as a value, so `1 R[xx] *` gave `(*,)`, `(1, 2) Z.. *` gave ... (20 more lines)
19:43
rakudo: ugexe++ created pull request #6774:
RakuAST: fix heredoc body scoping and premature consumption
19:47
rakudo/lizmat-42: a2b1a53304 | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
Make sure ::Name::Part.is-empty always returns a Bool

The ::Simple and ::Expression cases were returning 1 or 0 instead, whereas the ::Empty case *did* return True
19:54
rakudo: lizmat++ created pull request #6775:
Make sure ::Name::Part.is-empty always returns a Bool
rakudo/lizmat-40: 4fa2be82f8 | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
Make sure ::Name::Part::Simple returns a Bool
20:03
20:57 Pixi joined 21:27 Pixi` joined 21:30 Pixi left 21:32 Pixi` left 22:16 Pixi joined
Geth rakudo/main: b22a0daf20 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/name.rakumod
Make sure ::Name::Part.is-empty always returns a Bool (#6775)

The ::Simple and ::Expression cases were returning 1 or 0 instead, whereas the ::Empty case *did* return True
22:30
[Coke] what's the plan for merging PRs? Do we need an approval from someone? Or is just being post-release and passing all tests the bar.? 22:31
lizmat I feel like the latter?
Geth rakudo/main: 97788fa42b | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
RakuAST: don't warn about a sunk tr/// or user-defined term (#6772)

Previously a node without its own `PERFORM-CHECK` fell back to the one on `RakuAST::Expression`, which treats every sunk expression as a useless use. `RakuAST::Transliteration` and `RakuAST::Term::Named` are the only such nodes that can have an effect of their own. As such
  `$_ = "abc"; tr/a/x/;` and a call to a user-defined `term:<foo>` both
... (11 more lines)
22:32
[Coke] ok. I can merge some stuff in the evening here and do a blin run (in general, not necessarily today) 22:33
Geth rakudo/main: 5f8a56a69f | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 14 files
Change ::Name::Part::Empty to ::Name::Part::EmptyEdge (#6771)

To more clearly indicate that these can only occur as the first or last part of a RakuAST::Name object
[Coke] there's a bunch of PRs that passed all the tests back from August, also 22:35
lizmat indeed... but those would require some more getting acquainted with then again, and it's too late for me now to do that :-) 22:36
[Coke] yah, didn't mean tonight. 22:40
will merge #6774 #6773 #6770 if they pass. 22:42
lizmat ++[Coke]
Geth raku.org: hankache++ created pull request #327:
Fix run command in README
23:02
raku.org: hankache++ created pull request #328:
UI Polish
23:17