🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
releasable6 Next release in ≈2 days and ≈11 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
Geth problem-solving: patrickbkr++ created pull request #478:
Solution for #455 - New Script Wrappers		 07:10
07:23 donaldh left
ab5tract does anyone have an example of a metaprefix::hyper expression? I'm having trouble conjuring an incantation 08:40
what is going on with `xx-fixed-in-rakuast.rakutest`? it only runs 99 of the tests? 09:21
09:29 donaldh joined
Geth L10N-Complete/main: fca0871030 | (Elizabeth Mattijsen)++ | 12 files
Initial commit after cat-licensing the L10N distro
 11:10
L10N-Complete/main: 09a70b8125 | (Elizabeth Mattijsen)++ | Changes
0.0.1
 11:13
ab5tract t/12-rakuast/xx-fixed-in-rakuast.rakutest (Wstat: 256 Tests: 99 Failed: 5) 12:03
Failed tests: 63-65, 88, 95
what's the point of having a test file to ensure we don't regress if it's not checked and contains regressions? 12:04
lizmat I guess the point is that if someone does see a regression, it can be acted upon (albeit a bit late) ?
ab5tract one shouldn't push changes that cause regressions in the first place. now it's just up to whoever has time or patience to deal with, which hardly seems fair 12:07
lizmat true, but sadly testing with RAKUAST=1 is not in CI yet, afaik ? 12:08
ab5tract maybe not, but we were counting test successes/failures pretty consistently for RAKUDO_RAKUAST=1 12:09
lizmat I'll make sure it's clean before release 12:10
it's probably my fault anyways :-)
ab5tract I think we should comment out test 99 as well until it doesn't cause the rest of the tests to be ignored 12:11
lizmat: cheers :)
Geth rakudo/main: 61541d63f5 | ab5tract++ | src/Raku/ast/expressions.rakumod
Remove unnecessary WhateverApplicable

This class is only required for the Apply* family, so remove it now to avoid any potential confusion later.
lizmat meh, looks like the failure of xx-fixed made into my reference result, which is why I didn't see it :-( 12:28
Geth rakudo/main: 498bb93ada | ab5tract++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Adjust xx-fixed-in-rakuast.rakutest

Due to some weirdness around using `try` with
  `throws-like`, "throws wrong error" tests have
been commented out and the total number of tests has been adjusted.
  (The weirdness involves subsequent tests becoming part
of the first `try throws-like` subtests, even across the scope boundary).		 12:30
ab5tract lizmat: what do you mean by reference result here? 12:31
ohh, you mean the list of pass/fail test names?
lizmat the output I diff against to see changes
yup
ab5tract gotcha
lizmat also, your commits should have been marked with RakuAST: no ? 12:32
ab5tract ah, probably
Geth rakudo/main: 840e3eaf5b | (Elizabeth Mattijsen)++ | src/Raku/ast/compunit.rakumod
RakuAST: make sure $?FILE is a relative path

This to ensure some packagers reproducibility logic won't fire, now that $?FILE is actually in the string heap (since 313dfb7df0fd).
This means that $?FILE will have slightly different semantics once we switch to 6.e		 12:33
lizmat jdv [Coke] 61541d63f5 and 498bb93ada are RakuAST commits
linkable6 (2025-06-25) github.com/rakudo/rakudo/commit/61541d63f5 Remove unnecessary WhateverApplicable
(2025-06-25) github.com/rakudo/rakudo/commit/498bb93ada Adjust xx-fixed-in-rakuast.rakutest
lizmat m: say Q|class A { has $.a = :() }|.AST # I wonder whether :() is being interpreted as a no-arg call on ":" 12:42
camelia ===SORRY!=== Error while compiling EVAL_0
BEGIN time calls only supported for simple constructs so far
at EVAL_0:1
lizmat m: say Q|class A { has $.a = Signature.new }|.AST # is fine 12:43
camelia RakuAST::StatementList.new(
RakuAST::Statement::Expression.new(
expression => RakuAST::Class.new(
name => RakuAST::Name.from-identifier("A"),
body => RakuAST::Block.new(
body => RakuAST::Blockoid.new(
Ra…
lizmat m: say Q|:()|.AST # is also fine
camelia RakuAST::StatementList.new(
RakuAST::Statement::Expression.new(
expression => RakuAST::FakeSignature.new(
RakuAST::Signature.new(
parameters => $( )
)
)
)
)
lizmat m: my enum E <one>; class A { has $.a = one }; dd one === A.new.a 12:57
camelia Bool::True
lizmat m: my enum E <one>; role A { has $.a = one }; dd one === A.new.a
camelia Bool::False
lizmat m: my enum E <one>; class A { has $.a = one }; dd A.new.a
camelia E::one
lizmat m: my enum E <one>; role A { has $.a = one }; dd one, A.new.a, one === A.new.a # wtf ? 13:00
camelia E::one
E::one
Bool::False
ab5tract m: Q| my enum E <one>; role A { has $.a = one }; dd one, A.new.a, one === A.new.a |.AST.EVAL 13:02
camelia Could not instantiate role 'A'; exception details:

Unknown compilation input 'qast'
in any IMPL-COMPILE-DYNAMICALLY at src/Raku/ast/code.rakumod line 410
in any at src/Raku/ast/code.rakumod line 148
in sub at src/Rak…
lizmat meh
ab5tract :(
m: Q| my enum E <one>; class A { has $.a = one }; dd one, A.new.a, one === A.new.a |.AST.EVAL 13:04
camelia ===SORRY!===
Unknown compilation input 'qast'
lizmat the failure of === in that case feels like a dispatch issue 13:08
patrickb lizmat: Is CWD the right base to make $?FILE relative to? I.e. is CWD guaranteed to be set to the lib path at that point in the code? 13:18
lizmat what else could be used at that point ?
m: my enum E <one>; class A { has $.a = one }; dd one =:= A.new.a 13:20
camelia Bool::True
lizmat m: my enum E <one>; role A { has $.a = one }; dd one =:= A.new.a
camelia Bool::False
lizmat the difference between "class" and "role"
m: my enum E <one>; role A { has $.a = one }; dd one =:= A.new(:a(one)).a 13:24
camelia Bool::True
lizmat so it's something in the default assignment
m: my enum E <one>; my $one := one; role A { has $.a = $one }; dd one =:= A.new.a
camelia Bool::True
patrickb An ugly hack would be to cycle through all the lib paths and pick the one that is the longest prefix of $?FILE. 13:29
lizmat how would one get at the lib paths at that time ? 13:53
I think the enum issue boils down to: 13:57
m: my enum A <a>; dd a =:= a.clone
camelia Bool::False
lizmat m: my enum A <a>; dd a.WHICH
camelia ValueObjAt.new("A|0")
lizmat since enums are a value type, a clone should return the invocant
Geth rakudo/main: 398ac8a5b9 | (Elizabeth Mattijsen)++ | src/core.c/Enumeration.rakumod
Make Enumeration:D.clone return invocant

Because instantiated Enumerations are value types, a .clone should return the invocant unaltered, as there can only be one of a value type.
Because Enumeration:U would also need to return the invocant, take ... (14 more lines)		 14:14
roast: b17e4bfd84 | (Elizabeth Mattijsen)++ | S12-enums/thorough.t
Add test for #5599
 14:19
rakudo/main: 8b10ad12d4 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Remove test for now fixed #5599
 14:20
rakudo/main: b9765b477e | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
RakuAST: Mark failing tests in RakuAST also as TODO

It looks like the RakuAST implementation has taken on some of the issues that the legacy implementation has. Todo those tests for now, at least for the 2025.06 release.		 14:30
lizmat basically +3 issues in RakUAST, and -1 in legacy and RakuAST
jdv lizmat: k 14:31
lizmat ab5tract: sorry, this feels like all I could do without causing further potential ecosystem fallout
m: say Q|sub a(uint $a --> uint) { $a }; a 18446744073709551615|.AST.EVAL 14:43
camelia -1
lizmat but take away the return constraint:
m: say Q|sub a(uint $a) { $a }; a 18446744073709551615|.AST.EVAL 14:44
camelia 18446744073709551615
lizmat ab5tract: willing to take that on?
ab5tract hmm, maybe... 14:50
but it looks like the same behavior in the base compiler? 14:52
lizmat m: sub a(uint $a --> uint) { $a }; say a 18446744073709551615 14:53
camelia -1
ab5tract ah, so I guess it's a dispatch issue
m: dd my uint $a = 18446744073709551615
camelia -1
lizmat ab5tract: right, the idea it being fixed in RukuAST?
and now not anymore ?
ab5tract ohh, interesting
bisectable6: Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL == -1 15:37
bisectable6 ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight
ab5tract, Output on all releases: gist.github.com/66d54d97d996d38df5...7d1f4bf5c4 15:38
ab5tract, Bisecting by exit code (old=2023.02 new=2023.04). Old exit code: 1
ab5tract, bisect log: gist.github.com/4180365d5a208d7f81...1e6d5448d4
ab5tract, (2023-03-01) github.com/rakudo/rakudo/commit/97...15b050cecd
ab5tract, Bisecting by output (old=2022.12 new=2023.02) because on both starting points the exit code is 1 15:39
ab5tract, bisect log: gist.github.com/3731ef808b54f56696...37e788abcd
ab5tract, (2023-01-02) github.com/rakudo/rakudo/commit/2d...556c6a886e
ab5tract, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
ab5tract, bisect log: gist.github.com/84d8e6ebcf907ed599...cdbd72693d
ab5tract, ⚠ New output detected, please review the results manually
ab5tract, Output on all releases and bisected commits: gist.github.com/450b524c242c8b521e...e4426a1613
ab5tract bisectable6: help 15:40
bisectable6 ab5tract, Like this: bisectable6: old=2015.12 new=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # See wiki for more examples: github.com/Raku/whateverable/wiki/Bisectable
lizmat I'd try with old=2024.01 or so 15:41
ab5tract I always forget how to hold this thing :)
bisectable6: old=2024.01 exit 0 if Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL == -1 15:42
bisectable6 ab5tract, On both starting points (old=2024.01 new=b9765b4) the exit code is 0 and the output is identical as well
ab5tract, Output on both points: «»
lizmat say missing ?
ab5tract bisectable6: old=2024.1 exit 0 if Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL == -1
bisectable6 ab5tract, Cannot find revision “2024.1” (did you mean “2024.12”?)
ab5tract yeah that woiuld fix the useless use, but I think I'm supposed to involve exit or something? 15:43
bisectable6: old=2023.01 exit 0 if Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL == -1
bisectable6 ab5tract, Cannot find revision “2023.01” (did you mean “2025.01”?)
ab5tract bisectable6: old=2023.02 exit +(Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL == -1) 15:44
bisectable6 ab5tract, Bisecting by exit code (old=2023.02 new=b9765b4). Old exit code: 1
lizmat the suspense is killing... :-)
ab5tract gar, that's opposite
I think I may have killed the poor bot
lizmat don't matter in this case ?
bisectable6 ab5tract, bisect log: gist.github.com/e46db5547f22aa9267...9477ad0961 15:45
ab5tract, (2023-03-01) github.com/rakudo/rakudo/commit/97...15b050cecd
lizmat meh, false positive
ab5tract yup
let me throw a try in there too
bisectable6: old=2023.02 exit +(try Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL != -1)
bisectable6 ab5tract, Bisecting by exit code (old=2023.02 new=b9765b4). Old exit code: 0 15:46
ab5tract, bisect log: gist.github.com/1739cd5ebc2efcc2fa...a1b54916f0
ab5tract, (2023-03-01) github.com/rakudo/rakudo/commit/97...15b050cecd
ab5tract bisectable6: old=2024.01 exit +(try Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL != -1) 15:47
bisectable6 ab5tract, On both starting points (old=2024.01 new=b9765b4) the exit code is 1 and the output is identical as well
ab5tract, Output on both points: «»
lizmat bisectable6: old=2024.1 say Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL
bisectable6 lizmat, Cannot find revision “2024.1” (did you mean “2024.12”?)
lizmat bisectable6: old=2024.01 say Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL
bisectable6 lizmat, On both starting points (old=2024.01 new=b9765b4) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «18446744073709551615␤»
lizmat huh?
ab5tract bisectable6: old=2023.08 exit +(try Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL != -1) 15:48
bisectable6 ab5tract, On both starting points (old=2023.08 new=b9765b4) the exit code is 1 and the output is identical as well
ab5tract, Output on both points: «»
lizmat bisectable6: old=2024.01 say Q| sub a(uint $a --> uint) { $a }; a 18446744073709551615 |.AST.EVAL
ab5tract yeah that's certainly weird
bisectable6 lizmat, Bisecting by output (old=2024.01 new=b9765b4) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/cec16442f05e40d7ab...a8e8fa1834
lizmat, There are 2 candidates for the first “new” revision. See the log for more details
ab5tract ah, that seems to work better than worrying about the exit code 15:49
7b4ba29c3fa39cf580c273004db3ab278e59cdee 15:50
linkable6 (2025-03-19) github.com/rakudo/rakudo/commit/7b4ba29c3f RakuAST: only generate return handlers when there's a chance of explicit return
lizmat it's not 57fcb1f1b07229e3 for sure 15:52
linkable6 (2025-03-19) github.com/rakudo/rakudo/commit/57fcb1f1b0 RakuAST: dont' decont return values of rw routines
ab5tract alright, will take a look 15:58
Geth rakudo/main: 62915529b8 | (Elizabeth Mattijsen)++ | lib/RakuAST/L10N.rakumod
RakuAST: some maint / dev on RakUAST::L10N

  - added sub fresh-translation-file
  - added sub missing-translations
  - allow calling read-hash without args to get core translations
  - some code cosmetics and doc fixes		 16:12
ab5tract this is pretty strange... 16:40
bisectable6: old=2024.01 say Q| sub a(uint $a) { $a }; a 18446744073709551615 |.AST.EVAL 16:42
bisectable6 ab5tract, On both starting points (old=2024.01 new=6291552) the exit code is 0 and the output is identical as well
ab5tract, Output on both points: «18446744073709551615␤»
lizmat ab5tract: yeah, it's the adding of the return constraint that does it 17:11
Geth rakudo/main: 60a72b05c0 | (Elizabeth Mattijsen)++ | src/core.c/Process.rakumod
Make $*PROGRAM-NAME *always* assignable

It would become unassignable if BEGIN $*PROGRAM had been executed. And we want to use that in roast as a replacement for $?FILE, which will become a relative path		 17:19
rakudo/main: 15ab56c464 | (Elizabeth Mattijsen)++ | 2 files
Use $*PROGRAM instead of $?FILE in 'use lib'

As $?FILE will become a relative path, which could cause havoc on testing if not testing from the "base" directory		 17:21
roast: ae67421edb | (Elizabeth Mattijsen)++ | 321 files
Use $*PROGRAM instead of $?FILE in 'use lib'

As $?FILE will become a relative path, which could cause havoc on testing if not testing from the "base" directory		 17:22
ugexe there are going to be quite a few more instances that need to be replaced, such as github.com/Raku/roast/blob/ae67421...ation.t#L5 17:24
lizmat is on it
ugexe github.com/Raku/roast/pull/390/files - it is probably worth checking this PR for anywhere $?FILE is used that isn't on a `use lib` line 17:25
lizmat rak --modify-files '*.subst(q/$?FILE.IO.parent/,q/$*PROGRAM.parent/)' --extensions=t 17:28
to the rescue :-)
Geth roast: a4211ce40f | (Elizabeth Mattijsen)++ | 29 files
Use $*PROGRAM instead of $?FILE in 'use lib' (2)

As $?FILE will become a relative path, which could cause havoc on testing if not testing from the "base" directory		 17:29
lizmat ugexe++ for the nudges 17:30
ab5tract lizmat: what's the nqp op for checking if something is a lower case numeric? 17:33
I'm hoping that it also works for the type object
lizmat lower case numeric ? 17:34
ah, you mean native
ab5tract yeah, for some reason that label seemed weird. brain bubble 17:35
lizmat something with primspec 17:36
nqp::objprimspec ?
ab5tract that rings a bell, thanks for the hint :) 17:38
lizmat basically, if it's not 0, then it's a native 17:39
ab5tract now it does make me wonder whether the "right" place to fix this is in code.rakumod ... or maybe in p6typecheckrv itself?
lizmat as the error is in the legacy as well, it would seem p6typecheckrv would be the place? 17:40
ab5tract sure sure, make it harder on me ;)
lizmat heh...
ab5tract ahh, ok it's NQP at least 17:41
lizmat !! nqp::objprimspec(nqp::decont($type))
?? $value
looks like it's already DTRT ?
ab5tract yeah, just saw that! 17:43
ok, this is interesting 17:45
m: say Q| sub a(uint $a) { dd $a; $a }; a 18446744073709551615 |.AST.EVAL
camelia -1
18446744073709551615
ab5tract ... how? 17:47
lizmat m: sub a(uint $a) { dd $a; $a }; a 18446744073709551615 17:49
camelia -1
lizmat m: sub a(uint $a) { dd $a; $a }; say a 18446744073709551615
camelia -1
18446744073709551615
lizmat weird
afk for some fresh ice-cream
ab5tract enjoy!
lizmat &
ab5tract nine: any thoughts on what might be going on above? ^^ 17:51
17:54 librasteve_ joined 18:01 vrurg left 18:02 vrurg joined
ab5tract lizmat: looks like there is a bug in dd 18:17
m: sub a(uint $a) { dd $a; say $a; $a }; say a 18446744073709551615
camelia -1
18446744073709551615
18446744073709551615
18:28 bisectable6 left, greppable6 left, bisectable6 joined, greppable6 joined
lizmat interesting 19:13
m: 'my uint $a = 18446744073709551615; dd $a
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> my uint $a = 18446744073709551615; dd $a<HERE><EOL>
expecting any of:
…
lizmat m: my uint $a = 18446744073709551615; dd $a 19:14
camelia 18446744073709551615
Geth roast: a0a632a5be | (Elizabeth Mattijsen)++ | 9 files
Use .sibling( instead of .parent.child(

For more clarity and less code		 19:38
nqp/main: e4cc3c69e6 | (Elizabeth Mattijsen)++ | src/vm/moar/QAST/QASTCompilerMAST.nqp
Micro-optimize MASTing QAST::Stmt
 19:46
rakudo/main: aa4ac197c9 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for micro-opt in MASTing QAST::Stmt
 19:55
nine MoarVM bytecode might be worth a look for uint issues. Even nqp contains a lot of magic coercion that wont be apparent from the QAST 20:37
22:44 sivoais left 22:46 sivoais 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!