[Coke] is github.com/croservices/cro-webapp the canon repo? 00:05
Geth rakudo/main: 83baac0d6a | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
Use a lookup table for ::Name::Part::Simple.is-pseudo-package

Instead of repeated comparisons		 00:23
rakudo/main: 4fa2be82f8 | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
Make sure ::Name::Part::Simple returns a Bool
rakudo/main: 66c194ccb1 | (Will Coleda)++ (committed using GitHub Web editor) | src/Raku/ast/name.rakumod
Merge pull request #6770 from rakudo/lizmat-40

Use a lookup table for ::Name::Part::Simple.is-pseudo-package
rakudo/main: 5 commits pushed by (Nick Logan)++, (Will Coleda)++ 00:29
rakudo/main: 2202fa2992 | (Nick Logan)++ | 2 files
RakuAST: only take a listop invocant colon before any comma

Previously `comb sum 1000,2000: 2` failed to compile with "Only identical operators may be list associative" because the colon was parsed as part of the arguments to `sum`, even though `sum` had already seen a comma. The legacy grammar clears `$*INVOCANT_OK` when it parses a comma
  (4969e671ef), so the colon instead becomes the invocant colon of `comb`,
... (16 more lines)		 00:35
rakudo/main: 30b42b2460 | (Nick Logan)++ | 3 files
RakuAST: keep the invocant of a semicolon separated argument list

Previously `f(A: 1, 2; 3)` called the sub `f` with `\(((1, 2),), (3,))` instead of calling the method `f` on `A` with `\((1, 2), (3,))`. The semiarglist action rebuilds the argument list from the args of each section, which lost the invocant of the first one. Those args were also a single comma list, because `ArgList.from-invocant-list` left unpacking ... (5 more lines)
rakudo/main: 8de7894122 | (Will Coleda)++ (committed using GitHub Web editor) | 4 files
Merge pull request #6773 from ugexe/ugexe/rakuast-invocant-colon-after-comma

RakuAST: give an invocant colon to the listop it belongs to
rakudo: ugexe++ created pull request #6776:
Optimize $x ** 2 and $x²		 00:36
ugexe github.com/rakudo/rakudo/pull/6775/changes regresses ::("") to return False for .not-empty. also i suspect the code might be faster without the changes (adding nqp::hllbool) and just adding --> Bool to the return constraint instead 01:40
nqp::hllboolfor doesnt get inlined 01:41
s/not-empty/is-empty/ 02:02
Geth rakudo/revert-6775-lizmat-42: 1e88c7a0f7 | (Nick Logan)++ (committed using GitHub Web editor) | src/Raku/ast/name.rakumod
Revert "Make sure ::Name::Part.is-empty always returns a Bool (#6775)"

This reverts commit b22a0daf20825694b2e4c20e036b3fedee743c91.		 02:15
rakudo: ugexe++ created pull request #6778:
Revert "Make sure ::Name::Part.is-empty always returns a Bool"		 02:20
rakudo: ugexe++ created pull request #6779:
RakuAST: restore is-empty for an empty string name part and inline Bool return checks		 02:50
ugexe so --> Bool wasn't faster, but with that ^ PR it is. i fixed the is-empty regression and switched the hllboolfor stuff out for the --> Bool stuff and it does benchmark faster 02:52
Geth rakudo/main: 4 commits pushed by (Nick Logan)++ 03:40
04:50 japhb left 05:05 japhb joined
lizmat ok, so if I understand this correctly, specifying --> Bool (in the RakuAST bootstrap) is enough to turn an int into a proper Bool on return ? 08:46
do we consider resolvers as implementation-detail or not? 09:01
I would tend to think they are implementation detail?
Geth rakudo/lizmat-43: 613f7bf2b1 | (Elizabeth Mattijsen)++ | 5 files
RakuAST: use more lookup tables and --> Bool

  - affects some "is-xxx" public methods
  - add lookup table in IMPL-THUNK-ARGUMENTS because it makes sense		 10:22
rakudo: lizmat++ created pull request #6780:
RakuAST: use more lookup tables and --> Bool
rakudo/main: 4 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 10:23
10:26 hankache joined
Geth rakudo/lizmat-44: c88ce28f66 | (Elizabeth Mattijsen)++ | 10 files
RakuAST: some more --> Bool for "is-" accessors

So that they properly return a Bool rather than a 0 or 1		 11:10
rakudo: lizmat++ created pull request #6781:
RakuAST: some more --> Bool for "is-" accessors		 11:11
11:17 hankache left 11:18 ShimmerFairy left 11:34 ShimmerFairy joined
Geth rakudo/lizmat-45: 47e0efad8b | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
RakuAST: some fixes / streamlining in ::Name

  - fix ::Name.simple-identifier, it would return 0 rather than ""
   if not simple
  - use ::Name.set-colonpairs where possible, to avoid calling
   ::Name.add-colonpair in a loop
  - use condition as index in ::Name.indirect-lookup-part
  - changed name of variables to be more consistent ($type -> $name)
  - some code esthetics for readability		 12:19
rakudo: lizmat++ created pull request #6782:
RakuAST: some fixes / streamlining in ::Name
rakudo/lizmat-45: 747dc0006c | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
RakuAST: some more ::Name tweaks

  - use ternaries instead of separate unless
  - use condition as index for fetching part		 12:49
rakudo/lizmat-46: fd3aa4cc1a | (Elizabeth Mattijsen)++ | 7 files
RakuAST: remove :colonpairs from ::Name.from-identifier(-parts)

During compilation, a lot of identifiers are seen, and thus a lot of RakuAST::Name objects are being made. The convenience methods
  .from-identifier and .from-identifier-parts in core are always
used *without* the :colonpairs named argument.
... (9 more lines)		 13:45
rakudo: lizmat++ created pull request #6783:
RakuAST: remove :colonpairs from ::Name.from-identifier(-parts)
ugexe to be clear --> Bool is not always faster 13:51
you need to test
--> Bool allowed the other functions to inline. i tested that
(the other functions from yesterday)
lizmat but it would be faster than putting a hllboolfor(...,"Raku") in there 13:52
?
as that would increase the size of the method?
ugexe again, hllboolfor does not inline where you used it 13:54
lizmat right, but --> Bool will *not* prevent inlining
so if we want to make sure a method returns a Bool, --> Bool is the best way to do that, no?
ugexe it can put some of them over the inline limit. or the way its used can make it slower because it changes between bool and int a bunch
yes, but we still need to be aware of the performance characteristics of what we change and not just assume a general rule 13:55
lizmat well, if the method is exposed in Raku, we expect a Bool to be returned for a flag? or will be settle on a 0 or 1 ?
*we 13:56
ugexe we would od the same thing we've always done
all the ones you changes are almost certainly fine 13:57
well i think anyway
lizmat yeah, the ones that are in implementation classes
I didn't touch, nor the ones that were already expected to return a Bool
ugexe i mean i see one in class RakuAST::VarDeclaration::Simple
basically all im saying is if something you do makes it not get inlined anymore then you should be aware of it before merging, mostly so i am aware of changes to the performance characteristics overall 14:00
Geth rakudo: ugexe++ created pull request #6784:
RakuAST: declare Bool returns on predicates		 14:06
ugexe meant to push that up last night
fwiw (and you may already know this) the fastest way is generally no signature using ?? True !! False 14:09
lizmat that's not what I saw on my benchmarks yesterday
ugexe its what i see in mine 14:10
lizmat you're also on Apple Silicon, right?
if so, what was your benchmark?
ugexe yes
gist.github.com/ugexe/972a50197c7c...a1b904209e here is just one example 14:13
plain ?? True !! False 28ns, --> Bool with an int body 34ns, --> Bool with ?? True !! False 33ns
lizmat so shouldn't we QAST to a ternary ?? True !! False if we see --> Bool in the sig ? 14:15
ugexe no 14:19
that turns anything into a bool
lizmat you mean, it would be equivalent to --> Bool() ? 14:20
ugexe sort of. --> Bool now isn't like the Raku user level --> Bool constraint
lizmat that is understood :-) 14:21
but you can't have a --> Bool anyway if there's a return statement in a body
so --> Bool really means: make sure the "fall off" value is a Bool
so if ?? True !! False is the fastest way to do that, why don't we ? 14:22
ugexe because then it isnt checking anything
the 'return' thing just means we need to improve things to work with return or to rewrite the functions that currently return to drop off 14:23
lizmat but we were already clear on that? that --> Bool doesn't check anything, just converts to Bool ?
ugexe a body that accidentally falls off with a node, a Str or a Failure would just become True/False
lizmat we don't have Failures in the RakuAST bootstrap? 14:24
ugexe --> Bool on a node method converts only a native int. Anything else that isn't a Bool still throws
lizmat but it is slower because it checks for int, is what you're saying 14:25
?
ugexe github.com/rakudo/rakudo/pull/6784
with that is 1ns slower, so the same 14:26
with the benefit of the type check actually working
anyways im off to work
lizmat I guess I'll merge 6784 and then either close my PRs or resolve the collisions 14:28
Geth rakudo/main: 5 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 14:59
[Coke] did a run through 8de7894122 - after a redo, have a single failure with Injector on f20534c, complaining about multi-dim arrays 15:00
linkable6 (2026-10-01) github.com/rakudo/rakudo/commit/8de7894122 Merge pull request #6773 from ugexe/ugexe/rakuast-invocant-colon-after-comma
[Coke] f20534c was RakuAST: refuse a hash shape that is not a single type 15:01
Geth rakudo/lizmat-45: 6 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 15:03
[Coke] github.com/coke/raku-blin-release-results
Geth rakudo/lizmat-46: 6 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 15:04
[Coke] lizmat: is one of these PRs getting rolled back?
github.com/rakudo/rakudo/wiki/ChangeLog-Draft
releasable6: next
releasable6 [Coke], Next release in ≈22 days and ≈3 hours. There are no known blockers. 46 out of 68 commits logged
[Coke], Details: gist.github.com/9ee2bd4a5c3d2d1ee7...08c82f6a4a
[Coke] er, maybe it was all in the gist link here, not sure I added everything to the changelog draft last night. 15:05
ugexe [Coke]: im inclined to say it isn't a regression. legacy (and rakuast prior to the commit Blin points at) just ignored the shape so it wasn't doing anything. now it fails at compile time to tell them that instead of silently doing nothing 15:09
so Injector needs a PR
Geth rakudo/lizmat-43: 10 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/6...284e6577b3		 15:48
17:59 japhb left
Geth rakudo/main: 6611063c03 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 5 files
RakuAST: use more lookup tables and --> Bool

  - affects some "is-xxx" public methods
  - add lookup table in IMPL-THUNK-ARGUMENTS because it makes sense		 18:13
rakudo/main: 9c7786470b | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 6 files
RakuAST: some more --> Bool for "is-" accessors

So that they properly return a Bool rather than a 0 or 1
rakudo/main: aff385f36f | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/name.rakumod
RakuAST: some fixes / streamlining in ::Name

  - fix ::Name.simple-identifier, it would return 0 rather than ""
   if not simple
  - use ::Name.set-colonpairs where possible, to avoid calling
   ::Name.add-colonpair in a loop
  - use condition as index in ::Name.indirect-lookup-part
  - changed name of variables to be more consistent ($type -> $name)
  - some code esthetics for readability
  - use ternaries instead of separate unless
  - use condition as index for fetching part		 18:14
rakudo/lizmat-46: 1d4d418926 | (Elizabeth Mattijsen)++ | t/12-rakuast/name.rakutest
RakuAST: fix conflict resolve snafo
 18:38
lizmat m: dd RakuAST::Name::Part::Simple.new("MY").is-pseudo-package 18:49
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("MY").is-pseudo-package
expecting any of:
argument list
…
lizmat c: HEAD dd RakuAST::Name::Part::Simple.new("MY").is-pseudo-package
committable6 lizmat, ¦HEAD(aff385f): «Bool::True␤»
lizmat c: HEAD dd RakuAST::Name::Part::Expression.new(RakuAST::StrLiteral.new("MY")).is-pseudo-package # feels to me this should also be True, ugexe ? 18:50
committable6 lizmat, ¦HEAD(aff385f): «Bool::False␤»
19:16 japhb joined
Geth rakudo/lizmat-47: fa6b0755da | (Elizabeth Mattijsen)++ | src/Raku/ast/name.rakumod
RakuAST: give ::Name::Part::Expression its own .is-pseudo-package

It would seem only right that if an expression evaluates to a pseudo-package name, it should be marked as a pseudo package.
This moves the lookup hash for pseudo package names into the RakuAST::Name::Part base class as an IMPL-xxx method		 19:19
rakudo: lizmat++ created pull request #6785:
RakuAST: give ::Name::Part::Expression its own .is-pseudo-package		 19:21
rakudo/lizmat-47: 4 commits pushed by (Elizabeth Mattijsen)++
rakudo/lizmat-48: 380fb3fef9 | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: turn ::Type.is-known-to-be(.exactly) into single ternary

With a --> Bool signature to convert the result into a Bool		 19:48
rakudo: lizmat++ created pull request #6786:
RakuAST: turn ::Type.is-known-to-be(.exactly) into single ternary		 19:50
[Coke] c: HEAD try { ::("Error") } 20:01
committable6 [Coke], ¦HEAD(aff385f): «»
[Coke] c: HEAD my $x = "Error"; my $title; try { ::($x); $title ~~ s:g/ << $word >> //; } 20:02
committable6 [Coke], ¦HEAD(aff385f): «===SORRY!=== Error while compiling /tmp/5s16AvgjlQ␤Variable '$word' is not declared. Did you mean any of these: '&words',␤'&ord'?␤at /tmp/5s16AvgjlQ:1␤------> $title; try { ::($x); $title ~~ s:g/ << <HERE>$word >> //; }␤ «exit code = 1»»
[Coke] c: HEAD my $x = "Error"; my $title; try { ::($x); $title ~~ s:g/ << $x >> //; }
committable6 [Coke], ¦HEAD(aff385f): «»
[Coke] c: try { ::('borf') } 20:17
committable6 [Coke], ¦try: «Cannot find this revision (did you mean “all”?)»
[Coke] c: HEAD try { ::('borf') }
committable6 [Coke], ¦HEAD(aff385f): «»
[Coke] c: HEAD try { ::('borf') }; try { ::('borf') };
committable6 [Coke], ¦HEAD(aff385f): «»
[Coke] ... if I launch a REPL, and run that try command ones, I get a Nil back. If I up arrow and run it again, I get WARNING: unhandled Failure detected in DESTROY.
I have a raku/doc test script that does this repeatedly to look up if a bit of text is an object, and at some point (guessing 2026.09), the script started emitting a ton of the unhandled Failures. 20:18
lizmat hmmm... cannot repro on HEAD 20:20
[Coke] I'll see if I can golf it 20:21
... but not right now
Geth rakudo/lizmat-49: b6c6383765 | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: streamline ::Type.IMPL-EXPR-QAST

  - instead of if !foo / else, reverse and do if foo / else
  - create local copy of $!name for faster access
  - collapse a level of if into an elsif		 20:26
rakudo: lizmat++ created pull request #6787:
RakuAST: streamline ::Type.IMPL-EXPR-QAST
rakudo/main: 2191a57a8d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 7 files
RakuAST: remove :colonpairs from ::Name.from-identifier(-parts) (#6783)

During compilation, a lot of identifiers are seen, and thus a lot of RakuAST::Name objects are being made. The convenience methods
  .from-identifier and .from-identifier-parts in core are always
used *without* the :colonpairs named argument.
... (9 more lines)		 20:27
rakudo/main: 3b50b57e42 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/name.rakumod
RakuAST: give ::Name::Part::Expression its own .is-pseudo-package

It would seem only right that if an expression evaluates to a pseudo-package name, it should be marked as a pseudo package.
This moves the lookup hash for pseudo package names into the RakuAST::Name::Part base class as an IMPL-xxx method		 20:28
lizmat and that concludes my hacking for today 20:29
Geth rakudo/main: c62dc64d54 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/type.rakumod
RakuAST: streamline ::Type.IMPL-EXPR-QAST (#6787)

  - instead of if !foo / else, reverse and do if foo / else
  - create local copy of $!name for faster access
  - collapse a level of if into an elsif		 22:47

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!