🦋 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.
JimmyZhuo ===SORRY!=== 04:03
Redeclaration of symbol '%_'.
at lib/Test.rakumod:69
Redeclaration of symbol '$?CLASS'.
at lib/Test.rakumod:68
Redeclaration of symbol '::?CLASS'.
at lib/Test.rakumod:68
%_
RakuAST::VarDeclaration::Simple<4923585009792>
RakuAST::Method<4923582445440>
----------------------------------
$?CLASS
RakuAST::Type::Capture<4923496484976>
RakuAST::RoleBody<4923556529664>
JimmyZhuo nine: these three are both in ast-lexical-declarations and generated-lexical-declarations 05:16
Geth rakudo/main: 7addb39da2 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: use low level op for binding our-scoped constants when loading

Scope's BIND-KEY won't be available until we've loaded the setting.		 08:23
rakudo/main: 7d4800940f | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix call to VMNull when calling before entering frame where sub's declared

Fixes: class Foo { ... }; Foo.new; class Foo { sub foo() { }; method new() { foo } }
Geth rakudo/main: 0a4260b3a9 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: fix accidental sinking of bound values

As with assignment only the target can be sunk. The operands are very much used.		 10:31
lizmat nine: the previous commit seems to have lost 6 spectest files ? 10:34
t/spec/S06-operator-overloading/imported-subs.t 10:35
nine Huh...my latest spectest run is still at 1275
lizmat ok I'll pull for the last commit and run again
meh, wrong branch 10:36
nine slowly exhales 10:38
lizmat sorry... :-(
JimmyZhuo nine: do you have a idea how to fix it? or which place is right? 10:39
colabti.org/ircloggy/raku-dev/2025-03-12#l18
I found the '$_ =:= self' part doesn't work at all, will change it to nqp::eqaddr($_, self) 10:42
nine =:= should be exactly the same as eqaddr
JimmyZhuo I tested it always false, but eqaddr is true 10:43
nine Is a negation involved? I certainly have made the mistake of writing !$_ =:= self instead of !($_ =:= self) 10:45
JimmyZhuo I give it a try again. but the real problem is '%_', '$?CLASS' and '::?CLASS' are both in ast-lexical-declarations and generated-lexical-declarations' 10:48
nine In which test case and with what local changes? 10:51
JimmyZhuo change $_ =:= self to nqp::eqaddr($_, self), and the lib/Test.rakumod breaks 10:53
nine which line? 10:55
I can't see your screen from here :0
JimmyZhuo $ RAKUDO_RAKUAST=1 ./rakudo-m lib/Test.rakumod > debug.txt$ RAKUDO_RAKUAST=1 ./rakudo-m lib/Test.rakumod > debug.txt
===SORRY!===
Redeclaration of symbol '%_'.
at lib/Test.rakumod:69
Redeclaration of symbol '$?CLASS'.
at lib/Test.rakumod:68
Redeclaration of symbol '::?CLASS'.
at lib/Test.rakumod:68
for self.IMPL-UNWRAP-LIST(self.ast-lexical-declarations) { 10:56
my $lexical-name := $_.lexical-name;
if $lexical-name && !nqp::eqaddr($_, self) {
changed !$_ =:= self to !nqp::eqaddr($_, self) 10:57
nine Oh, yes, there's definitely a precedence error in "if $lexical-name && ! $_ =:= self" 10:58
Should be if $lexical-name && ! ($_ =:= self)
nine You have uncovered a bug there. Now the question is how we can recognize that those symbols are not in fact duplicates. 10:59
JimmyZhuo yeah 11:00
nine Maybe the object you find in %lookup is exactly the same as $_? In that case, since it's the same AST node, it cannot really be a duplicate 11:02
JimmyZhuo I saw some code somewhere about duplicates 11:06
I forget the place 11:07
nine in the generated-lexical-declarations loop we already write the generated declarations into %lookup. In the ast loop when checking for whether a key exists in the lookup you could also check whether it's the same object after all 11:08
JimmyZhuo oh, see it 'nqp::push(@not-if-duplicate, $decl);' in ast-lexical-declarations() 11:10
Geth rakudo: zhuomingliang++ created pull request #5812:
add redeclaration exception of placeholder parameter		 11:29
JimmyZhuo nine++ for help 11:31
nine JimmyZhuo: why did you switch the two loops? 11:47
I guess it's to detect the error on the placeholder instead of the actual original declaration? 11:48
Geth rakudo/main: cb0a49313a | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: fix bogus warning about "unused" expressions in short circuiting operators

Fixes: myy $a = "hi"; $_ eq "hi" and $_ = "$_ you" with $a
JimmyZhuo nine: I have to push 'my $foo' to %lookup first, so I can check the $^foo later 11:52
so the error will be same as the non-RAKUAST frontend 11:53
nine JimmyZhuo: unfortunately your change regresses t/spec/6.c/S04-declarations/my-6c.rakudo.moar t/spec/S02-types/hash.t t/spec/S04-declarations/multiple.t t/spec/S04-declarations/my-6e.rakudo.moar t/spec/S05-metasyntax/interpolating-closure.rakudo.moar t/spec/S06-advanced/stub.rakudo.moar t/spec/S06-traits/is-copy.t 11:55
While it's true that hash.t does redeclare the %h variable, that's surprisingly legal in Raku: 11:58
m: my %h; my %h; say "still here"
camelia Potential difficulties:
Redeclaration of symbol '%h'.
at <tmp>:1
------> my %h; my %h<HERE>; say "still here"
still here
nine Not that this is just a warning
lizmat JimmyZhuo: OOC, is there a reason you use colabti.org/ircloggy/raku-dev/2025-03-12#l18 instead of irclogs.raku.org/raku-dev/2025-03-12.html#05:16 ? 12:10
JimmyZhuo lizmat: the later is very slow here, sometimes I can't open it 12:12
lizmat ok, understood :-)
there's too much not cached at the moment ;-( 12:13
JimmyZhuo nine: If I switch back the two loops, I don't know how to check the placeholder 12:15
nine JimmyZhuo: I'm fine with switching the loops. Was just wondering if that was required or just a leftover from debugging. 12:16
JimmyZhuo: but those regressions need to be taken care of 12:17
JimmyZhuo yeah
Geth rakudo/main: cb52491816 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: fix bogus warning about "unused" values used in atomic assignment

Fixes: my atomicint $s; $s ⚛= 0		 12:23
JimmyZhuo { 12:29
my $x = 2;
my $y := $x;
my $x = 3;
is $y, 3, 'Two lexicals with the name in same scope are the same variable';
}
so it is about !($_ =:= self) 12:30
nine No, because self is the LexicalScope there
First step is to figure out the rules for when to warn and when to fail 12:31
That's really the hardest part of the whole RakuAST thing: discovering the undocumented rules. It's nice that they are tested automatically via those spectests, but spectests are not really readable documentation that explains anything.
JimmyZhuo m: {my $x = 2; my $y := $x; my $x = 3; say($y);} 12:33
camelia Potential difficulties:
Redeclaration of symbol '$x'.
at <tmp>:1
------> {my $x = 2; my $y := $x; my $x<HERE> = 3; say($y);}
3
JimmyZhuo how the old frontend pass the test and throw exception with -e
nine "Potential difficulties" is just a warning. 12:34
So add-worry instead of add-sorry
JimmyZhuo $ RAKUDO_RAKUAST=1 ./rakudo-m -e ' my $x = 2; my $x = 3; ' 12:46
Potential difficulties:
Redeclaration of symbol '$x'.
at -e:1
Redeclaration of symbol '$x'.
at -e:1
------> my $x = 2; my $x<HERE> = 3;
two worries 12:47
with comment 12:48
# self.add-worry:
# $resolver.build-exception: 'X::Redeclaration',
# :symbol($lexical-name), :what($_.declaration-kind);
it will only one
$ RAKUDO_RAKUAST=1 ./rakudo-m -e 'my $x = 2; my $x = 3; '
Potential difficulties:
Redeclaration of symbol '$x'.
at -e:1
------> my $x = 2; my $x<HERE> = 3;
so I just comment it? or I add cond to check if it is RakuAST::VarDeclaration? 12:50
nine Certainly needs a check. 12:56
JimmyZhuo nine: I force pushed the pr 12:58
have to update again ,placeholder is not worry 13:01
pushed, I think it's ok now 13:02
nine Did you check the spectests for any regressions? 13:07
JimmyZhuo I just check these you posted here, full spectest takes longtime for me 13:09
nine It's worth it :) I have rarely done any change that didn't cause any unexpected regressions 13:10
JimmyZhuo it's about half a hour here 13:13
lizmat JimmyZhuo: how many cores does your machine have ?
JimmyZhuo E3-1230v1 cpu
4 cores 8 threads, 10+ years old 13:14
lizmat have you tried setting: TEST_JOBS=8 environment variable ?
JimmyZhuo +++ Compiling blib\CORE.c.setting.moarvm 13:19
The following step can take a long time, please be patient.
Stage start : 0.000
Stage parse : 76.182
Stage syntaxcheck: 0.000
Stage ast : 0.000
Stage optimize : 9.441
Stage mast : 12.815
Stage mbc : 2.335
lizmat which makes it roughly 2x as slow as the M1 I work on
with TEST_JOBS=8 you should be able to run the spectest in about 8 minutes or so ? 13:20
nine You don't have to sit an watch it for that half an hour :)
We now make it through compilation of CORE.d.setting! What this really means is that we can actually load the newly compiled CORE.c setting and survive running its mainline 13:23
lizmat whee!
JimmyZhuo that's very good 13:25
nine Also the diff with workarounds in the setting is getting smaller and smaller 13:29
nine Btw. a common one of these workarounds is s/Perl6::Metamodel::/Metamodel::/g. I.e. we need to refer to the metamodel by the same name as user space code does. I think that the metamodel was available via the Perl6:: namespace was just a side effect of loading Perl6::Grammar and Perl6::Actions. 13:57
lizmat couldn't we do that aliasing in bootstrap.nqp ? 15:34
timo it would probably be nice if we could give it a deprecation notice if we see it used. that's probably something for Actions or even Optimizer to look at 15:37
lizmat rakkable: eco-provides Perl6::Metamodel 15:42
rakkable lizmat, Running: eco-provides Perl6::Metamodel, please be patient!
lizmat, Found 15 lines in 10 files (8 distributions):
lizmat, gist.github.com/54e62071fd433331c0...3fc9271a26
lizmat that looks overseeable
nine timo: this change affects only the setting itself. Outside the setting Perl6::Metamodel has always just been called Metamodel. 16:07
timo oh!
nine m: Perl6::Metamodel 16:08
camelia Could not find symbol '&Metamodel' in 'GLOBAL::Perl6'
in block <unit> at <tmp> line 1
nine m: say Metamodel::ClassHOW.HOW.name(Metamodel::ClassHOW) 16:09
camelia Perl6::Metamodel::ClassHOW
lizmat do you feel that's an issue? 16:15
I mean it's the same issue as:
m: constant Foo is Int; say Foo.^name
camelia ===SORRY!=== Error while compiling <tmp>
Missing initializer on constant declaration
at <tmp>:1
------> constant Foo is Int<HERE>; say Foo.^name
lizmat m: my constant Foo is Int; say Foo.^name
camelia ===SORRY!=== Error while compiling <tmp>
Missing initializer on constant declaration
at <tmp>:1
------> my constant Foo is Int<HERE>; say Foo.^name
lizmat m: my constant Foo = Int; say Foo.^name
camelia Int
nine No, why would it? 16:33
lizmat I was wondering why you showed the Metamodel::ClassHOW.^name 16:34
nine The name it knows itself by is inconsequential
lizmat indeed, that's why I wondered whether I was missing something :)
nine Just to show that it's definitely not available as Perl6::Metamodel::ClassHOW but Metamodel::ClassHOW refers to that exact class
lizmat understood 16:36
Geth rakudo/main: b707a43746 | (Stefan Seifert)++ | src/Raku/ast/term.rakumod
RakuAST: give Term::Self a second chance to resolve

At the time Term::Self's PARSE runs, the surrounding methodish may not have declared its implicit self. No worry, we only need it resolved at CHECK time, so try again there.		 16:58
nine We are through the build! 17:00
lizmat wow! 17:15
nine Of course trying to run anything immediatly crashes because of my &*WHENEVER-BLOCK-TO-ADD := Nil; in Supply 17:19
m: my &callable := Nil
camelia Type check failed in binding; expected Callable but got Nil (Nil)
in block <unit> at <tmp> line 1
nine m: my &*callable := Nil
camelia ( no output )
nine Why is it suddenly alright to ignore a bind constraint on a dynamic variable? 17:20
lizmat good question
m: my &*FOO = 42 17:21
camelia Type check failed in assignment to &*FOO; expected Callable but got Int (42)
in block <unit> at <tmp> line 1
lizmat m: my &*FOO := 42
camelia ( no output )
lizmat hmmm not limited to Nil
nine This is what I really hate about Raku. It's not consistent at all, that was just marketing. It's got literally thousands of rules many of which are frankly just non-sensical. 17:28
[Coke] Perhaps improved consistency can be a target of 6.f? 17:33
lizmat yeah... agree,... also the handling of generic needs to be overhauled 17:38
subjects for a RCS2 consensus :-)
nine 554 spectest files passing with a full RakuAST build. That's better than expected 17:48
[Coke] Nice. 17:51
ugexe i'm always harping on about consistency in reviews/issues, and largely because i'm not sure how you can improve inconsistency after-the-fact if we also want to maintain strong backcompat. consistency needs to be strongly considered ahead of any and all changes 18:19
nine absolutely 18:20
The biggest problem with removing inconsistencies is that these rules are just not documented at all. Spectests make terrible documentation for humans.
lizmat especially if the enshrine implementation details :-( 18:22
[Coke] installed all the missing packages from SmokeMachine and the unbitrot page and kicked off a blin run 19:42
let me know if we get to a point where we want a blin run with RAKUAST turned on
Geth rakudo/bootstrap-rakuast: 45 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/f...c6215cdada		 19:45
nine 3500 lines of diff to get us through the bootstrap. The good news is that there are no spectest regressions :)
[Coke] I forgot how painful it is to do anything on train wifi in the states. 19:49
ggoebel nine: good to see you back at RakuAST :-) Are you keeping a log of the inconsistencies and pain points that frustrate you? Might minimize the bus factor and increase the odds that someone other than you can work on them. 20:45
nine Only in the form of IRC posts 20:49
ugexe something something feed LLM irc logs something something LLM makes a nice list of pain points 20:54
nine That's....not the worst LLM suggestion I've heard so far :D 20:55
Geth rakudo/main: 4a8ee5d22d | (Stefan Seifert)++ | 3 files
RakuAST: fix while/loop loop statement mods when we skip CHECK time

StatementModifier::WhileUntil needs us to thunk loop-condition, condition- modifier and expression but crucially it only needs this if we're not a block statement and we're not sunk. The problem is that at BEGIN time we don't know that yet.
Previously we therefore thunked at CHECK time, but we may not even get a CHECK time if the statement is executed at BEGIN time. Thus we now thunk at BEGIN time just in case and if it turns out the statement is sunk, we undo that thunking again.		 21:29
[Coke] ⏳ 565 out of 2295 modules processed (24.61%) 22:06

Powered by Cro and the Raku® Programming Language.

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

Thank you!