🦋 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.
MasterDuke here's an interesting situation 01:39
m: q|my $১০kinds;|.EVAL; CATCH { dd $_ }
camelia X::Syntax::Variable::Numeric.new(what => "variable", pos => 6, filename => "/home/camelia/EVAL_0", line => 1, directive-filename => Any, column => Any, modules => [], is-compile-time => 1, pre => "my \$১০", post => "kinds;", highexpect => [])
==…
MasterDuke m: q|my $১০kinds;|.AST.EVAL; CATCH { dd $_ } 01:40
camelia X::Syntax::Confused.new(reason => "Two terms in a row", pos => 4, filename => "/home/camelia/EVAL_0", line => 1, directive-filename => Any, column => Any, modules => [], is-compile-time => Bool::True, pre => "my \$", post => "১০kinds;", highexpect…
MasterDuke it looked like an easy fix. add the missing `[<?{ $*IN-DECL }> <.typed-panic: "X::Syntax::Variable::Numeric">]?` to `token variable`, so it looks identical to the legacy version 01:41
but that didn't change anything. and then i noticed the error is coming from `eat-terminator`. it looks like it goes straight through <statementlist> and then dies in <eat-terminator> 01:44
Geth ¦ problem-solving: clsn assigned to samcv Issue Regex matching and combining characters github.com/Raku/problem-solving/issues/471 01:45
MasterDuke ah, the legacy version of `token variable` has a different ordering of the alternations 01:52
it uses `|` for the alternations, which is LTM, so you would think the order doesn't matter...but let's try re-ordering to be the same as legacy... 01:54
JimmyZhuo nine: 'class D { method d { $!d = 1 }};' vs 'role E { method e { $!e = 1 }}' , the Raku Action performs a '$COMPUNIT.check($RESOLVER)' for the 'class D', but didn't for 'Role E', I added 'RakuAST::Var::Attribute' check to RakuAST::Var::Attribute, and it's only works for the 'class D', How to make 06:42
it works for role ?
I added 'X::Attribute::Undeclared' check to RakuAST::Var::Attribute 06:43
nine JimmyZhuo: I'm confused. The CompUnit's check should always be called - unless there was a panic before we get there 06:59
tellable6 nine, I'll pass your message to JimmyZhuo
nine I'm working on a problem where a Seq contained in a List gets consumed prematurely when the List is destructured by a for loop. 07:38
The problem comes from List's Capture coercer method. It contains this loop: 07:39
nqp::istype(($v := nqp::atpos($!reified, $i)),Pair) ?? nqp::bindkey($hash, $v.key.Str, $v.value) !! nqp::push($list,$v) while nqp::islt_i(++$i,$elems)
The Seq gets consumed because the ternary here gets sunk and nqp::push returns the pushed value. Thus the value (our Seq) gets sunk which makes it consume the iterator its based on. 07:40
Now my real problem is: I think that's entirely correct behavior.
m: my $i = 2; class Foo { method sink() { say "{self.^name} sank" } }; class Bar is Foo { }; $i > 1 ?? Foo.new !! Bar.new while $i-- 07:44
camelia Bar sank
Bar sank
nine This ^^^ seems to agree with me.
But for some reason: 07:45
m: my $i = 3; class Foo { method sink() { say "{self.^name} sank" } }; use nqp; my $l := nqp::list; class Bar is Foo { }; $i > 1 ?? nqp::push($l, Foo.new) !! nqp::push($l, Bar.new) while $i--
camelia ( no output )
nine m: use nqp; say nqp::push(nqp::list, "pushed") 07:46
camelia pushed
nine The QAST does know that it should be sunk: - QAST::Op(while) <sunk> :statement_id<12> $i > 1 ?? nqp::push($l, Foo.new) !! nqp::push($l, ... 07:48
And: - QAST::Op(if &infix:<??>) <sunk okifnil> ?? nqp::push($l, Foo.new) !!
Geth rakudo/main: 02e32a22ea | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: don't create implicit slurpy hash when there's a capture parameter

In method foo(|c) the c parameter already slurps all named args. There's no need for an implicit *%_ in such cases, so we can avoid the effort of setting it up.		 08:54
rakudo/main: 773f9b9793 | (Stefan Seifert)++ | 2 files
RakuAST: don't sink expressions with loop modifiers

For unknown reason we must not sink the bodies of loops created from statement modifiers. This restriction may not even have been intentional, but it's certainly being relied upon by code in the setting like this from List.Capture:
... (8 more lines)
nine Well, I guess it's just yet another one of these thousands of rules.
JimmyZhuo $ RAKUDO_RAKUAST=1 ./rakudo-m --ll-exception -e 'role E { method e { $!e = 1 }};' 10:04
No $!e attribute in E
at src\Perl6\Metamodel\AttributeContainer.nqp:91 (E:\OpenSource\Rakudo\blib/Perl6/Metamodel.moarvm:get_attribute_for_usage)
from src\Raku\ast\variable-access.rakumod:303 (E:\OpenSource\Rakudo\blib/Perl6/BOOTSTRAP/v6c.moarvm:IMPL-EXPR-QAST)
from src\Raku\ast\expressions.rakumod:58 (E:\OpenSource\Rakudo\blib/Perl6/BOOTSTRAP/v6c.moarvm:IMPL-TO-QAST)
tellable6 2025-03-18T06:59:25Z #raku-dev <nine> JimmyZhuo: I'm confused. The CompUnit's check should always be called - unless there was a panic before we get there
JimmyZhuo nine: for role: IMPL-EXPR-QAST is executed before check 10:05
lizmat JimmyZhuo: that feels.. valid
?
JimmyZhuo nine: and for class, check is excuted before IMPL-EXPR-QAST
lizmat I mean, the error
Geth rakudo/main: ee50ab5be3 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Fix stupid copy-pasto in exception class naming

The name of the class is **without** .new! Fixes #5798		 10:08
JimmyZhuo lizmat: not for consistency 10:09
Geth rakudo/main: c5fa7bb363 | (Elizabeth Mattijsen)++ | t/12-rakuast/highlight.rakutest
RakuAST: fix highlighting test
 10:15
rakudo/main: fba808c224 | (Elizabeth Mattijsen)++ | src/Raku/ast/resolver.rakumod
RakuAST: make fallback error handling more informative

Since the name of the exception that was attempted to be resolved is known, show that. That would have helped a *lot* when trying to fix #5798 :-(		 10:26
JimmyZhuo nine: I found the problem: the IMPL-COMPOSE of RakuAST::Role calls IMPL-FINISH-ROLE-BODY, which calls IMPL-QAST-BLOCK before checktime, while RakuAST::Class does not. so I can't do the check for role 10:38
but I don't know how to deal it
lizmat bisectable6: old=2025.01 say Q|my role A { has $.a = 42 }|.AST.statements[0].expression 10:41
bisectable6 lizmat, Bisecting by output (old=2025.01 new=fba808c) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/a45b5a4d174eca9d61...23f29878a7
lizmat, (2025-03-05) github.com/rakudo/rakudo/commit/00...58d63c9e14
nine JimmyZhuo: CHECK should not have any influence on IMPL-QAST-BLOCK and vice versa. 10:46
JimmyZhuo: however it's possible that IMPL-QAST-BLOCK fails because of a condition that you'd report as error in PERFORM-CHECK. That sucks and my only solution there is to try to detect it in IMPL-QAST-BLOCK and fail gracefully. 10:47
lizmat: oh that superfluous .new looks super devious. Confusing for sure 10:52
lizmat: in the bootstrap-rakuast branch the exception type fallback is already implemented :/ 10:53
lizmat sorry about that... 10:54
lizmat nine: did you look / fix the problems with "make test" t/12rakuast tests in the bootstrapped version ? 11:25
feels like I'm going to be in your way :-(
nine Haven't looked at make test in quite a while 11:28
lizmat ok, the role one is baffling me... the other ones I can work on, fwiw 11:29
m: use lib "lib"; use NativeCall::Compiler::GNU; use NativeCall::Compiler::MSVC; say NativeCall::.keys 11:30
camelia (Compiler Types)
lizmat hmmm... for me, that says (Compiler) locally
m: use NativeCall::Compiler::GNU; use NativeCall::Compiler::MSVC; say NativeCall::.keys 11:31
camelia (Compiler Types)
lizmat probably because "use lib 'lib'" doesn't work for Camelia, and thus gets the installed versions, and that *does* supply NativeCall::Types 11:32
but should it ?
nine You sure you want to dig into that particular cluster fuck? :D 11:38
Importing module symbols is lexical - except when it isn't
lizmat yeah... I'll just add a "use NativeCall::Types" to the test file 11:40
Geth rakudo/main: f646c5a244 | (Stefan Seifert)++ | 2 files
RakuAST: fix missing condition modifier on statements with loop modifiers

Commit 95f6c5b4e9697d6a2fc66ade32d2333d375e0ac8 made us omit condition modifiers on statements that also carry loop modifiers as the condition would be handled inside the thunk. For StatementModifier::WhileUntil however we do not thunk in certain conditions. Then we do have to wrap the expression in the condition modifier.
Fixes: foo unless bar while baz;
lizmat nine: a gist about the role issue: gist.github.com/lizmat/4b7fb14673c...e23c98d136 11:41
nine 1237 fully bootstrapped
lizmat: so apparently a RakuAST::Parameter did not get its begin time 11:43
lizmat there is no parameter? 11:44
unless maybe implicit in the role parameterization ?
I mean, the role body is transmogrified into a sub, no ? 11:45
nine RakuAST::RoleBody isa RakuAST::Sub
The signature at least has the ::$?CLASS capture
lizmat but is that something that you would need to specify in programmatically creating a role ? 11:46
Geth rakudo/main: f9dd316561 | (Elizabeth Mattijsen)++ | t/04-nativecall/24-cpp_param_letter.t
Make test always work

Apparently the test file depends on NativeCall::Types being implicitely imported, but sometimes it apparently isnt't. Add a "use NativeCall::Types" to make sure the necessary stuff is always known		 11:47
nine Btw. since I notice that I do complain about Raku a lot lately. The lexical import cluster fuck I mentioned is on me. When I implemented lexical module loading I really had no idea what I was doing. I took it as far as I could without having to ask the hard questions and that's where we are now. 11:49
lizmat right, understood, and I won't hold it against you: on the contrary 11:50
only people that actually make things, make mistakes
hopefully we learn from them :-)
nine Well I took the lesson to heart and stay far away from language design =) Precicely because it's so hard to anticipate all implications 11:51
Geth rakudo/main: 69dc86fa5a | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: fix deparsing of 3²²

The power value is the real thing already and doesn't need additional deparsing.		 12:04
rakudo: zhuomingliang++ created pull request #5820:
Throw X::Attribute::Undeclared, pass the test of "class D { method d { $!e = 1 }};"		 12:15
lizmat bisectable6: old=2025.02 say Q|s/o/x/|.AST.EVAL 12:17
bisectable6 lizmat, On both starting points (old=2025.02 new=69dc86f) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Use of uninitialized value $_ of type Any in string context.␤Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.␤ in block <unit> at EVAL_0 line 1␤===SORRY!===␤Unknown compilation input 'qast'␤»
lizmat bisectable6: old=2025.01 say Q|s/o/x/|.AST.EVAL
bisectable6 lizmat, Bisecting by exit code (old=2025.01 new=69dc86f). Old exit code: 0
lizmat, bisect log: gist.github.com/f655b3f481ad15438e...68993d070a
lizmat, (2025-02-16) github.com/rakudo/rakudo/commit/cd...da2f4ac311
Geth rakudo/bootstrap-rakuast: 27 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/1...094f5f66ba
nine 1244 fully bootstrapped. That's exactly the state of 2 weeks ago :) 12:18
lizmat nine: is say Q|s/o/x/|.AST.EVAL something that's fixed on the bootstrapped version ?
cd2ed227be broke t/12-rakuast/regex-substitution.rakutest 12:19
linkable6 (2025-02-16) github.com/rakudo/rakudo/commit/cd2ed227be RakuAST: work around "Misordered regex compilation" problem
JimmyZhuo nine++ for the hard work
nine rakudo (bootstrap-rakuast *<>)> RAKUDO_RAKUAST=1 ./rakudo-m -e 'say Q|s/o/x/|.AST.EVAL' 12:20
Type check failed in assignment to $grammar; expected Mu but got Raku::Grammar (Raku::Grammar.new() ...)
lizmat and without RAKUDO_RAKUAST=1 ?
nine Can't run the bootstrapped version without RAKUDO_RAKUAST=1: Missing or wrong version of dependency 'gen/moar/BOOTSTRAP/v6c.nqp' (from 'gen/moar/CORE.c.setting') 12:21
That grammar error comes even with Q||.AST.EVAL
lizmat ack 12:22
I'm just going through the "make test" errors, making sure "make test" gets clean before the release on Sun 12:23
perhaps we should disable the tests that are failing atm, and re-instate them after the bootstrapped version becomes main ? 12:24
bisectable6: old=2025.01 my $foo; say Q|++$foo while $foo < 5|.AST.EVAL 12:25
bisectable6 lizmat, On both starting points (old=2025.01 new=69dc86f) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Use of uninitialized value of type Any in numeric context␤Nil␤ in block <unit> at EVAL_0 line 1␤»
lizmat heh
bisectable6: old=2024.08 my $foo; say Q|++$foo while $foo < 5|.AST.EVAL
bisectable6 lizmat, On both starting points (old=2024.08 new=69dc86f) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Use of uninitialized value of type Any in numeric context␤Nil␤ in block <unit> at EVAL_0 line 1␤»
lizmat m: my $foo; say Q|++$foo while $foo < 5|.AST.EVAL; say $foo 12:27
camelia Use of uninitialized value of type Any in numeric context
Nil
5
in block <unit> at EVAL_0 line 1
lizmat so it does work, just produces a warning somewhere 12:28
nine As it should. After all $foo is uninitialized when entering the loop, yet we are doing a numeric comparison on it 12:30
Geth rakudo/main: a2f7c1aa7c | (Elizabeth Mattijsen)++ | t/12-rakuast/statement-mods.rakutest
RakuAST: remove unwanted Statement::Expression

Apparently in an older version of the Raku Grammar this was needed for the statement modifier, but not anymore. A nice simplification!		 12:32
lizmat nine: right
nine Huh...that's an odd one. From the very commit introducing RakuAST::StatementModifier it has taken a RakuAST::Expression (which a Statement::Expression isn't) 12:36
lizmat well, the grammar doesn't create it (anymore) 12:41
m: my $foo; say Q|++$foo while $foo < 5|.AST.statements[0].loop-modifier
camelia RakuAST::StatementModifier::While.new(
RakuAST::ApplyInfix.new(
left => RakuAST::Var::Lexical.new("\$foo"),
infix => RakuAST::Infix.new("<"),
right => RakuAST::IntLiteral.new(5)
)
)
lizmat bisectable6: old=2025.01 my $foo; say Q|++$foo while $foo < 5|.AST.statements[0].loop-modifier 12:53
bisectable6 lizmat, On both starting points (old=2025.01 new=69dc86f) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «RakuAST::StatementModifier::While.new(␤ RakuAST::ApplyInfix.new(␤ left => RakuAST::Var::Lexical.new("\$foo"),␤ infix => RakuAST::Infix.new("<"),␤ right => RakuAST::IntLiteral.new(5)␤ )␤)␤»
lizmat bisectable6: old=2024.08 my $foo; say Q|++$foo while $foo < 5|.AST.statements[0].loop-modifier
bisectable6 lizmat, On both starting points (old=2024.08 new=69dc86f) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «RakuAST::StatementModifier::While.new(␤ RakuAST::ApplyInfix.new(␤ left => RakuAST::Var::Lexical.new("\$foo"),␤ infix => RakuAST::Infix.new("<"),␤ right => RakuAST::IntLiteral.new(5)␤ )␤)␤»
lizmat ok, apparently a long time ago already
bisectable6: old=2025.01 say Q|my $a is default(42)|.AST.DEPARSE 12:54
bisectable6 lizmat, Bisecting by output (old=2025.01 new=69dc86f) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/82812fd829ca6c4270...397a291833
lizmat, (2025-03-16) github.com/rakudo/rakudo/commit/51...43cf7fbf7b
lizmat aha, self inflicted :-)
Geth rakudo/main: 9f58a3420e | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/Raku/ast/variable-access.rakumod
throw X::Attribute::Undeclared, pass the test of "class D { method d { $!e = 1 }};" (#5820)
 12:57
rakudo/main: b6346aad0b | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: fix deparsing of traits with argument

If the argument is already some sort of expression with parentheses, don't add any extra ones. This is just for readability, as the extra parentheses would be ignore on parsing anyway		 13:00
[Coke] Getting close to release day.
Going to kick off final blin run this afternoon
lizmat [Coke]: working on making "make test" clean
[Coke]: if you could make an issue for the result of the blin run, that would help tremendously 13:01
the gist only is just too noisy 13:02
[Coke] Yes, sorry about that.
Were you able to address any issues in that one or no?
(the problem is the markdown is enormous and you have to cut a lot of it, but not the helpful parts.) 13:03
It'll take a day to run the next one, I'll convert that gist into a ticket after kicking off another round.
lizmat timo++ found an assuming / precomp bug in there that probably hit a number of modules that has been fixed now 13:04
so I'm expecting a cleaner blin run in that respect
Geth rakudo/main: cc2e941981 | (Stefan Seifert)++ | 2 files
RakuAST: ensure all routines (and mainline) have $¢

Previously we declared it only in regex declarations, but apparently its also available for normal regex expressions.
Fixes: my $c; 'abc' ~~ /.{ $c = $¢ }/		 13:05
lizmat rakkable: eco-pro .assuming 13:06
rakkable lizmat, Running: eco-provides .assuming, please be patient!
lizmat, Found 65 lines in 44 files (32 distributions):
lizmat, gist.github.com/3fbdbdc7558168a7de...ab4d8b908e
lizmat [Coke]: ^^ potential blin errors fixed
Geth rakudo/bootstrap-rakuast: 27 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/7...0ec541045d
nine 1245
lizmat bisectable6: old=2025.01 say Q|my @matrix[2;2]; @matrix["0"; "0"] = 42|.AST.EVAL 13:09
bisectable6 lizmat, Bisecting by exit code (old=2025.01 new=69dc86f). Old exit code: 0
lizmat, bisect log: gist.github.com/3dd62355e3635291bc...b319524c8c
lizmat, (2025-03-09) github.com/rakudo/rakudo/commit/d6...c4ff433979
lizmat d6d3859 an example of a not so good commit message 13:11
nine indeed 13:12
Sadly by the time I committed I didn't know anymore in what specific case this helped. Came up as a bootstrap workaround 13:14
lizmat nine: we all are in such a situation every now and then 13:21
fwiw, reverting that makes my @matrix[2;2]; @matrix["0"; "0"] = 42 work again 13:22
nine m: my @matrix[2;2]; @matrix["0"; "0"] = 42 13:24
camelia Partially dimensioned views of shaped arrays not yet implemented. Sorry.
in block <unit> at <tmp> line 1
nine Apparently it's not even supposed to work?
lizmat m: use v6.e.PREVIEW; my @matrix[2;2]; @matrix["0"; "0"] = 42
camelia Partially dimensioned views of shaped arrays not yet implemented. Sorry.
in block <unit> at <tmp> line 1
lizmat huh?
nine Fails in exactly the same way with RakuAST for me 13:25
Geth rakudo/bootstrap-rakuast: afa24ab4d7 | (Stefan Seifert)++ | src/core.e/Grammar.rakumod
RakuAST: fix "Could not find symbol '&Compiler' in 'Grammar::HLL'"

Need to load NQP modules explicitly.
nine That's 1248
lizmat #1297
nine And no, I really don't know why we need to load NQP modules explicitly in the setting with RakuAST. Or rather why we don't with the old compiler.
lizmat github.com/rakudo/rakudo/issues/1297
m: my @matrix[2;2]; @matrix[0; 0] = 42 13:28
camelia ( no output )
lizmat it's the stringiness of the arguments that caused the NYI error to be shown
$ RAKUDO_RAKUAST=1 raku -e 'my @matrix[2;2]; @matrix["0"; "0"] = 42; dd @matrix' 13:31
Array.new(:shape(2, 2), [42, Any], [Any, Any])
weird
nine Apparently works as intended when going through infix:<=> but not with whatever IMPL-ASSIGN-OP generates 13:34
lizmat m: my %h{Int}; say %h.of 13:38
camelia (Any)
lizmat m: my %h; say %h.of
camelia (Mu)
lizmat that feels... inconsistent ?
I guess that's one of the things we thought we fixed in RakuAST, but in the end didn't 13:39
m: say Q|my %h{Int}; %h.of|.AST.EVAL 13:40
camelia (Any)
lizmat bisectable6: old=2025.01 say Q|my %h{Int}; %h.of|.AST.EVAL
bisectable6 lizmat, Bisecting by output (old=2025.01 new=69dc86f) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/8905793bb6a7a59b4a...f880d8e510
lizmat, (2025-03-02) github.com/rakudo/rakudo/commit/24...a06f87e7bb
lizmat discussion at github.com/rakudo/rakudo/issues/5419 13:41
nine: suggest we revert 24bde349 and fix the spectest 13:43
nine Do we know whether this affects other spectests?
lizmat sadly the commit message doesn't mention the commit that changed the default originally 13:45
lizmat goes afk for a few hours& 13:49
nine It's commit 93e96b44e1b9d97efb388d376ad4d3bceb4176c6 13:51
releasable6 Next release in ≈4 days and ≈3 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
MasterDuke i don't remember. is it at all possible to get the name of the variable holding the object from a class's method? 15:21
m: class A { method a { say self.VAR.name } }; my $b = A.new; $b.a    # e.g., i want it to print '$b' 15:22
camelia No such method 'name' for invocant of type 'A'. Did you mean any of
these: 'are', 'none', 'note', 'take'?
in method a at <tmp> line 1
in block <unit> at <tmp> line 1
nine How could that work? It's perfectly fine to have multiple variables contain the same object 15:26
MasterDuke well, for what i want to use it for a list of name would be fine 15:28
m: class A { method a(\b:) { say b.VAR.name } }; my $b = A.new; $b.a 15:29
camelia $b
nine Honestly this sounds like a "if you need that, you want the wrong thing in the first place" 15:34
MasterDuke just more context in error/warn messages 15:35
nine JimmyZhuo: somehow commit 9f58a3420e978acd3f001236c31caf481fc63e98 regressed t/spec/S12-attributes/class.t 15:43
tellable6 nine, I'll pass your message to JimmyZhuo
linkable6 (2025-03-18) github.com/rakudo/rakudo/commit/9f58a3420e throw X::Attribute::Undeclared, pass the test of "class D { method d { $!e = 1 }};" (#5820)
nine I guess it's because it causes the class to get composed before we add the methods to the package 15:44
Geth rakudo/main: 507584f3ca | (Stefan Seifert)++ | 2 files
RakuAST: ensure sink is calculcated when generating QAST for subs/methods

We really need to have sink calculated before we generate QAST as it can gravely affect compilation output, by e.g. turning lazy loops into eager ones. In normal compilation flow this isn't an issue, but of course routines can be called at BEGIN time which means we also generate the QAST before CHECK time (at which we normally would calculate sink).
So force calculation when we generate QAST. We already did so before but just for role bodies (as those are always compiled at BEGIN time). Now we extend that to all subs and methods.		 15:48
nine 1250
[Coke] ~. 16:04
~
lizmat accidentally ran into this: 16:47
m: my %h{Str(Eny)}
camelia ===SORRY!===
Cannot find method 'value' on object of type QAST::Op
lizmat m: my %h{Str(Any)}
camelia ( no output )
lizmat m: my %h; %h<a> = 5 | 6; say %h<a> == 5 16:59
camelia any(True, False)
lizmat m: my %h{Str}; %h<a> = 5 | 6; say %h<a> == 5
camelia Type check failed for an element of %h; expected Any but got Junction (any(5, 6))
in block <unit> at <tmp> line 1
lizmat that's why I think the default constraint should be Mu for typed hashes, like it is for normal hashes 17:00
it shouldn't make a difference whether a Hash is typed or not
nine But what about the autoviv Typed hash problem? 17:02
lizmat that was a commit from 2013 17:03
I can't even find that code anymore in World, at least
I mean, in Actions duh 17:04
:{ } is the alternate syntax for creating object hashes 17:09
m: say :{ a => 5 | 6 }<a> == 5 17:10
camelia any(True, False)
lizmat there it *does* work
lizmat nine: looks like the last commit made us lose: t/spec/S12-attributes/class.t 17:51
No such method 'z-thunk' for invocant of type 'RT130748d'
in block <unit> at t/spec/S12-attributes/class.t line 161
nine No it's 9f58a3420e978acd3f001236c31caf481fc63e98 17:53
linkable6 (2025-03-18) github.com/rakudo/rakudo/commit/9f58a3420e throw X::Attribute::Undeclared, pass the test of "class D { method d { $!e = 1 }};" (#5820)
lizmat hehe, indeed, sorry old news :-) 17:58
Geth roast: b3429ef625 | (Elizabeth Mattijsen)++ | S09-typed-arrays/hashes.t
Assume Hash.of alwaysi defaults to Mu

Commit 7b7bab4a6c in 2013 assumed Any, as a follow up of
  github.com/rakudo/rakudo/commit/93e96b44e1b9d9 .
However, since then a lot has happened, and an inconsistency has crept in: ... (20 more lines)		 18:07
rakudo/main: d1466f7397 | (Elizabeth Mattijsen)++ | src/Raku/ast/variable-declaration.rakumod
Revert "RakuAST: make default value type of shaped hashes Any instead of Mu"

This reverts commit 24bde349be3938d39c2e6e4421f88ea06f87e7bb.
The original situation on RakuAST was correct, the test that instigated this commit has been corrected.		 18:08
lizmat bisectable6: old=2025.01 my num @a = -Inf .. 0e0; dd @a 18:40
bisectable6 lizmat, On both starting points (old=2025.01 new=d1466f7) the exit code is 0 and the output is identical as well 18:41
lizmat, Output on both points: «num = array[num].new()␤»
lizmat ok, this is getting weird: 18:44
m: my num @a = 1e0,2e0; @a = -Inf..0e0; dd @a # oddly enough doesn't throw, but doesn't re-initialize @a either 18:46
camelia num = array[num].new(1e0, 2e0)
lizmat m: use Test; my num @a = 1e0,2e0; throws-like { @a = -Inf..0e0 }, Exception, "foo" # but inside a throws-like, it throws ?? 18:48
camelia # Subtest: foo
1..2
ok 1 - code dies
ok 2 - right exception type (Exception)
ok 1 - foo
Geth rakudo: MasterDuke17++ created pull request #5821:
Add variable name if possible to warning about use of uninitialized numeric		 19:29
rakudo/main: ef38f301a8 | (Stefan Seifert)++ | src/Raku/ast/term.rakumod
RakuAST: hllize the result of topic calls

Method calls may call into foreign languages, so we need to hllize their results. We already did this for normal method calls. Topic calls were left out till now.
Fixes: .foo.raku # When .foo returns a BOOTHash		 20:45
nine 1251
A bunch of spectests in S06-currying fail due to .assuming issues 20:48
on bootstrap
Geth rakudo/main: 9d7abd04ad | (Stefan Seifert)++ | src/Raku/ast/statement-mods.rakumod
RakuAST: fix missing condition on statements with a given modifier

Similar to commit f646c5a244295c9f3336858c8de0afb3b41a6ae3 Same fix was needed for StatementModifier::Given
Fixes: say $_ if $_ > 3 given 1 # to not say		 21:52
nine 1259 fully bootstrapped.
Would be 1261, but t/spec/S32-list/categorize.t and t/spec/S32-list/classify.rakudo.moar suddenly fail (even on non-bootstrapped) 21:53
lizmat: I think that revert is responsible
lizmat ok, will look 22:55
hmmm... how can that revert affect the legacy grammar ? 22:56
ah, misunderstood 22:57
nine: confirmed it is the revert... but I will sleep on whether to change the test, or the way categorize and classify create their object hashes 23:15
so will look at that tomorrow
well, actually later today :-) 23:16

Powered by Cro and the Raku® Programming Language.

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

Thank you!