🦋 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 i'm back to looking at why `my $23kinds` doesn't throw `X::Syntax::Variable::Numeric` in RakuAST. it looks like it's somehow getting through EXPR (which is re-implemented in RakuAST instead of using the method from NQP like the legacy frontend does), without detecting that there's a variable declaration 00:44
so that gets it through `<statement>` and then `<statementlist>`, but doesn't get through `<.eat-terminator>` and dies with `two terms in a row` 00:46
but i'm really not sure how to debug further
Geth rakudo: zhuomingliang++ created pull request #5824:
A bunch of Undeclared Attribute check fixes.		 04:26
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
nine We cannot really merge the bootstrap branch because there's one commit in there that busts the old frontend. 08:34
The other reason I haven't merged it yet is that I want to see whether any of the remaining fixes will make some workaround obsolete 08:35
Geth rakudo/main: 7c62a5ad99 | (Jimmy Zhuo)++ | 2 files
A bunch of Undeclared Attribute check fixes.

This fixed some regression in t/spec/S12-attributes/class.t, and passed t/spec/S12-attributes/undeclared.t		 08:46
rakudo/main: a630609d53 | niner++ (committed using GitHub Web editor) | 2 files
Merge pull request #5824 from zhuomingliang/UndeclaredAttribute

A bunch of Undeclared Attribute check fixes.
nine 1281 courtesy of JimmyZhuo!
[Tux] Rakudo v2025.02-295-g9fe52a1d5 (v6.d) on MoarVM 2025.02-14-g3ecde0a0f
csv-ip5xs0.258 - 0.263
csv-ip5xs-201.124 - 1.231
csv-parser1.111 - 1.137
csv-test-xs-200.136 - 0.139
test1.834 - 1.836
test-t0.413 - 0.418
test-t --race0.269 - 0.269
test-t-205.044 - 5.054
test-t-20 --race1.240 - 1.265
 08:56
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth rakudo/main: 22 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/a...56fc81cf4d		 09:56
nine This is the risk-free part of the bootstrap-rakuast branch, i.e. the part that only touches RakuAST classes and should therefore be 0 risk for the release.
Only exception is one commit that adds code to src/Perl6/bootstrap.c/BOOTSTRAP.nqp. But that does not modify any existing code and instead just adds a new bootstrapped class that's used by the RakuAST frontend. Again, should be 0 risk. 09:57
With this merged, we should have far less conflicts when rebasing that branch as all of the AT-POS removal is in 09:58
lizmat nine: regarding the categorize / classify breakage in RakuAST: I will fix that after the release 09:59
as it will subtly change the object hashes created by classify and categorize 10:00
and I don't want to do that without a blin run
nine Makes sense. It's only a few more days anyway. 10:06
lizmat coming back on how to handle POPULATE without BUILDPLAN 10:09
nine: in your opinion, the POPULATE creation logic should be based on the meta-object, aka the actual class object 10:10
did I get that right ? 10:11
lizmat come to think of it: this actually poses a bigger question: how should one create classes programmatically? Through the MOP, or through building RakuAST trees and calling .EVAL on it? 10:13
nine Not sure. 10:14
MOP is completely fine for creating classes. After all that's what the compiler itself does
lizmat could / should we consider the MOP an implementation-detail in the future
nine no 10:15
lizmat so we'd have 2 ways of programmatically creating classes: one with RakuAST, and one with the MOP
nine Very rakuish 10:18
Though they are really complementing each other. It's just different layers 10:19
lizmat we've been playing with the idea to directly generate MAST from RakuAST at some point: would that still go through the MOP? 10:21
if not, then we'd have 2 ways of generating MAST, which would be bad? 10:22
nine The MOP has nothing to do with MAST 10:23
lizmat old situation:
grammar -> MOP -> QAST -> MAST 10:24
new situation:
grammar -> RakuAST -> MOP -> QAST -> MAST
of RakuAST would create MAST itself, then it would bypass the MOP -> QAST parts, no?
maybe we should have this discussion IRL in June :-) 10:25
Geth rakudo/bootstrap-rakuast: 14 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/0...c94e098467		 10:28
nine Good news! The workarounds that I was most worried about are no longer needed. All the bizarre errors went away, probably with the sink calculation fixes 10:29
MOP has nothing at all to do with QAST. Nothing.
QAST leads to executable code. MOP is used for creating objects.
lizmat I guess I wasn't fully awake yet: only one mention of QAST in the metamodel 10:30
TIL (again probably :-) 10:31
nine The thing that makes me really wonder is that the bootstrap branch passes 2 spectest files that main doesn't. No idea which of the workarounds left in that branch is so beneficial though 10:33
lizmat apart from the classify / categorize, right ? 10:34
nine Yes, those fail on both branches
t/spec/6.c/S32-io/file-tests.t and t/spec/S06-other/misc.t 10:35
lizmat ack
nine Oooh... t/spec/S06-other/misc.t is the one with X::Undeclared::Symbols
And t/spec/6.c/S32-io/file-tests.t failed because it's horribly written and scatters files/symlinks in the build directory and in /tmp and then stumbles over them when they already exist 10:37
I've had 10k perl6_roast* files in /tmp 10:38
So we're at 1283 now non-bootstrapped 10:43
Geth rakudo/main: 0730199b32 | (Elizabeth Mattijsen)++ | src/core.c/Numeric.rakumod
Add missing .Numeric to infix %

Spotted in #5823		 11:00
lizmat afk for a bit& 11:01
nine m: sub foo { dd @_; if rand <= 1 { dd @_ } }(1, 2) 11:15
camelia [1, 2]
[Bool::True]
nine m: sub foo(*@_) { dd @_; if rand <= 1 { dd @_ } }(1, 2)
camelia [1, 2]
[1, 2]
nine The totally inconsistent language of a 1000 rules
[Coke]: since you asked about this. @_ is one of the things I'd kill off completely. 11:17
lizmat yeah, implicit @_ is a perlism 11:25
nine github.com/Raku/old-issue-tracker/issues/1488 is such a great case of ad-hoc language design gone wrong. Someone comes across something unexpected, there's no discussion and when an incidental change makes the problem disappear this behavior is enshrined in a spec test. 11:31
Thing is the previous unexpected behavior is arguably totally correct!
The block in if True { } is a real block, not just a syntactic grouping. That's how it's advertised as "strangely consistent" and why you can give it a signature with if True -> $true { } 11:32
@_ is a magical auto-declaring variable that contains the surrounding block's positional arguments. Since the if statement's block is such a block, that's what it should be declared on. 11:33
m: sub foo { dd @_; if True -> $true { dd @_ } }(1, 2) 11:34
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variable '@_' cannot override existing signature
at <tmp>:1
------> sub foo { dd @_; if True <HERE>-> $true { dd @_ } }(1, 2)
nine After all it does complain about that if block having a signature in this example
lizmat he 11:36
m: my uint @a = 14256035878013490812; use nqp; dd nqp::atpos_u(@a,0) # this feels buggy 11:37
camelia -4190708195696060804
nine m: sub foo { dd @_; if True { dd @_ } }(1, 2)
camelia [1, 2]
[Bool::True]
nine But wrap it in another sub:
m: sub bar(*@_) { sub foo { dd @_; if True { dd @_ } }(1, 2) }()
camelia Too many positionals passed; expected 0 arguments but got 2
in sub foo at <tmp> line 1
in sub bar at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: my uint @a = 14256035878013490812; use nqp; my uint64 $a = nqp::atpos_u(@a,0); say $a 11:41
camelia 14256035878013490812
lizmat nine: looks like the auto-coerce of native uints to str is using int logic 11:43
nine Not surprised that there are problems left 11:46
I think I'm not gonna try fix that spectest about @_. As demonstrated the expectation there is non-sensical and makes a bad situation only worse. 11:47
lizmat agree, fwiw 11:48
nine If we can gather a bit more feedback from the usual suspects, I'd like to remove that test 11:49
timo yeah, turning the expectation to be explicitly about Routine (or whichever type/role it is that sub and method do) gets us additional special cases in the rules that you've already shown many of
nine I think all the existing behavior including the incidental pasisng of the test just comes from a check somewhere whether @_ is visible lexically or not with no regards of where it's actually declared. 11:50
JimmyZhuo less special rules make things simpler 11:51
Geth roast: 0b8c717e66 | (Stefan Seifert)++ | S06-signature/slurpy-params.t
Remove dubious test that only incidentally passed anyway

  github.com/Raku/old-issue-tracker/issues/1488 is such a great show case
of ad-hoc language design gone wrong. Someone comes across something unexpected, there's no discussion and when an incidental change makes the problem disappear this behavior is enshrined in a spec test.
... (26 more lines)		 11:56
rakudo/main: 01369236da | (Elizabeth Mattijsen)++ | 2 files
Fix Buf/Blob.join/raku for uints

Currently there appears to be a deficiency in the automatic coercion of a native 64bit integer with the most significant bit set, to a native string. This is probably because there is no special handling for that, and so the signed integer handling is used. Which isn't a problem if the msb is not set. ... (6 more lines)		 11:58
nine Shouldn't this be fixed in NQP instead? 11:59
lizmat probably, but it would take me multiple hours to figure out where that auto-coercion is happening, and we're close to a release 12:00
nine: unless you have an idea of where I should look?
nine I wouldn't let the release stress me. After all we've done just fine for 10 years with this bug. 12:02
The whole point of doing frequent regular releases is so that there's a next release soon and people don't rush to get half baked fixes and features in :) 12:03
QASTCompilerMAST.coercion is the place to start looking 12:05
Geth roast: a0eb4b9968 | (Stefan Seifert)++ | S06-signature/slurpy-params.t
Update plan after test removal in previous commit
 12:06
nine So much for rushing half baked fixes...
lizmat elsif $got == nqp::const::MVM_reg_uint64 { 12:08
%core_op_generators{'coerce_us'}($!mast_frame, $res_reg, $reg);
looks like it is already in ther 12:09
e
Geth roast: a3710eaf46 | (Stefan Seifert)++ | S06-signature/slurpy-params.t
Fix syntax error in test descriptions

Those test descriptions go all the way to include super helpful copy&pasteable code, but then stumble over a superfluous closing bracket
nine lizmat: in that case it's worth having a look at the generated mbc 12:11
[Coke] here's the result of the blin run gist.github.com/coke/a7866fff243d3...2a743e7204 - I will convert this to a ticket later today, but wanted to get it out there asap 12:12
is 7c62a5ad99 safe for a last minute merge?
linkable6 (2025-03-20) github.com/rakudo/rakudo/commit/7c62a5ad99 A bunch of Undeclared Attribute check fixes. 12:13
lizmat [Coke]: yeah, the problem with that commit, is the message: it's missing the RakuAST: header
nine: it probably is 12:14
but I'll first have a look at the blin run results
[Coke] Seeing a lot of commits...
patrickb Given that 1. Raku has a small user base, 2. we have Blin and 3. we don't guarantee compatibility across language versions; I support every endeavour to remove special cases and features in our implementation driven by increasing the consistency and decreasing the complexity in the *implementation* (in contrast to perceived consistency in the language, which is arguably harder to reason 12:15
about).
nine [Coke]: irclogs.raku.org/raku-dev/2025-03-...09:56-0002
[Coke] thanks, did see that. Still a large merge just before release. 12:17
(and post blin)
patrickb I do believe that a simpler implementation will reflect into a language that is easier to reason about once one accepts that it's necessary to partially understand the implementation and it's not just "magic". I.e. no abstraction is perfect.
On that note, what would be a good place to collect RakuAST implementation annoyances we might ponder to remove in the next language version? problem-solving? (For now I'd just collect them, deciding what to do could be a next step.) 12:21
lizmat problem solving 12:22
JimmyZhuo 1282 here 12:29
lizmat nine: looks like the remaining blin issues are with .assuming and precomp: 12:43
Serialization Error: missing static code ref for closure 'assumed.' (:1)
I assume this may caused by the use of "self" as the subroutine to be called, rather than putting that into a variable? 12:44
having: sub a($a,$b) { }, and &a.assuming(42) the generated sub is: 12:46
sub assumed.a ($b) {
self(42, $b)
}
nine I don't know the internals of assuming, so can't tell 12:47
lizmat ah, found the issue (sort of) 12:50
the problem occurs when a precompiled module A (with an .assuming) is used in a precompiled module B 12:51
gist.github.com/lizmat/4868dc2a33c...e87f54261d 12:53
ah, been able to golf it 12:55
updated the gist 12:56
precomping with: BEGIN my &b = &a.assuming(42); is the issue apparently
Geth rakudo/main: 2e637594c9 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: respect "is required" trait on named args

Fixes: sub foo(:$n is required, *%_) { }; foo(:x(1)) # to fail		 13:02
nine 1284
JimmyZhuo: the difference in test counts is due to one local change in t/spec I have which I intend to commit once we switch over 13:03
lizmat nine: perhaps we're missing a nqp::markcodestatic somewhere in the RakuAST.EVAL ? 13:11
patrickb github.com/Raku/problem-solving/issues/472 <- I've created a bucket for RakuAST implementation inconsistencies. Feel free to add to that ticket. Maybe I'll find the time to extract IRC rants and put them there. 13:15
nine patrickb: Piping the irc logs into an AI still sounds like a great idea to speed that up :D 13:16
lizmat: unlikely. That error usually means that the QAST is missing for that code object 13:17
lizmat nine: updated the gist so that is *not* using .assuming 13:20
JimmyZhuo I ask deepseek how to improve nqp or rakudo(i.e, give nqp a DFA feature), and it gives me a diff patch which looks good, but can't use at all.
lizmat nine: the odd thing is that the "say" isn't run either 13:21
JimmyZhuo and someone uses cursor + deepseek ?
lizmat nine: feels to me some basic issue with RakuAST and precomp 13:22
patrickb antononcube: I'm currently looking for a way to extract nines rants about inconsistencies in the language from the IRC logs. That might be a good job for an AI. Do you maybe want to give it a try? (Given you're our local AI expert.) 13:24
lizmat returning the whole compunit with .EVAL(:compunit) doesn't work either
nine lizmat: let me ask it from the other direction: what work has been done to ensure that BEGIN EVALed ASTs actually work with precomp? 13:25
lizmat I would not know the answer to that, but figured that setting compilation is precomp, and so some work has been done in that direction? 13:26
lizmat I mean, the new sprintf logic in 6.e is basically a precomped module? and that works? 13:27
o
nine nine@sphinx:~/rakudo.main (main *=)> echo 'use v6.e.PREVIEW; BEGIN zprintf "%s", "foo"' > lib/Foo.rakumod 13:31
nine@sphinx:~/rakudo.main (main *=)> rakudo -Ilib -e 'use Foo;'
===SORRY!=== Error while compiling -e
===SORRY!===
chars requires a concrete string, but got null
lizmat makes a mental note 13:32
nine: looking at ast/code/IMPL-STUB-CODE
it does not get run in the .EVAL case, should it not ? 13:33
nine It should be run as a BEGIN time effect
lizmat it's not with the code in my gist 13:34
at least, not before the error is thrown
timo > Serialization Error: missing static code ref for closure '<unit>' (:1) 13:38
that recent moarvm patch improves this exact error message
lizmat so this is the improved, or should something be merged and bumped ?
nine I was using an old rakudo 13:39
nine@sphinx:~/rakudo.main (main *=)> ./rakudo-m -Ilib -e 'use Foo;'
===SORRY!=== Error while compiling -e
===SORRY!===
Serialization Error: missing static code ref for closure '<unit>' (:1)
timo yeah 13:40
lizmat I'm afraid this is getting above my current level of understanding the nitty gritty bytecode stuff 13:41
timo i assume that just means we didn't add the code object in the right list so that it gets compiled into the same file 13:42
but i don't really know
nine timo's on the right track
lizmat World has something like:
my $code_ref_idx := self.add_root_code_ref($stub, $code_past); 13:43
self.context().sub_id_to_sc_idx(){$cuid} := $code_ref_idx;
in finish_code_object
timo /* Given a closure, locate the static code reference it was originally cloned 13:48
* from. */
nine And static code is ~~ the QAST that we generated 13:49
timo the code below that looks if there's a static_code, and if yes if that object has a SC assigned to it
lizmat i've further golfed the gist gist.github.com/lizmat/4868dc2a33c...e87f54261d
timo and if the static_code is null, or if the static_code has no SC, and if "fatal" isn't false (which i guess is used to turn this into a check instead of automatic explosion) it will give that serialization error 13:50
we don't give a different error message for whether static_code is null or if the static_code has no sc
i would naively expect it to be the second case, though 13:51
not sure if we can have a closure that doesn't have a static_code at all
lizmat afk for a few hours& 13:59
[Coke] moved from gist to ticket for blin:
github.com/rakudo/rakudo/issues/5825
if someone could copy over liz's comments from the gist at gist.github.com/coke/a7866fff243d3...a743e7204, I'd apprciate it (have to jump back on calls) 14:00
(nevermind, copied them over) - @lizmat, please continue with comments on the ticket, thanks! 14:06
nine 1285 14:39
Geth down? 14:51
liztormato Geth: help 14:53
timo Geth: help 14:54
Geth timo, Source at github.com/Raku/geth To add repo, add an 'application/json' webhook on GitHub pointing it to webhooks.liz.nl/?chan=%23raku and choose 'Send me everything' for events to send | use `ver URL to commit` to fetch version bump changes
timo liztormato: can't get help from geth when your messages are grey
liztormato Strange. Maybe Girhub is not delivering push 14:55
Messages Am afk at the moment. Won’t be able to check for at least an hour 14:56
nine 1286 16:29
I have looked through most of the remaining spec tests and found nothing that scared me. 16:42
I did notice that there are several test files where it's just that X::Undeclared vs. X::Undeclared::Symbols problem. I.e. the test expects the compiler to complain about a certain symbol and only that whereas the RakuAST frontend will report that and other unknown symbols in an exception that cover all of them. 16:43
lizmat that feels to me the specttest is too specific and should be made more general ? 16:46
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 16:47
rakudo/bootstrap-rakuast: 15 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/f...f22fd70bc2		 16:48
rakudo/main: 5386a7a25b | (Stefan Seifert)++ | 2 files
RakuAST: support EXPORTHOW
lizmat nine; I think those 16:50
nine: I think those where the ones you missed
nine indeed 16:51
Geth rakudo/main: 6e9504e3bc | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod
RakuAST: throw an X::Undeclared if there's only one undeclared symbol
 16:53
nine 1288!
lizmat nice! 16:54
nine I think this may actually be the appropriate fix. At least it fixes all 3 cases where I know that this was the only problem.
Also lets me get rid of that local patch to t/spec
lizmat getting back to the .assuming / precomp issue 18:26
nine: does RakuAST have something akin to CompilationContext ? 18:28
nine Yes, that RakuAST::IMPL::QASTContext that we pass around 21:27
Geth rakudo/main: 0e1c64761e | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod
RakuAST: fix copy pasta in resolver

Thanks to MasterDuke++ for catching this		 21:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!