🦋 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.
[Coke] f 00:55
ugexe f 01:22
Geth rakudo/main: c2282618bb | (Stefan Seifert)++ | src/Raku/ast/statement-mods.rakumod
RakuAST: fix statement modifier with stumbling over null values

We must not call .defined on a VMNull as VMNull does not have any methods at all. So bail out early if we got a null value on our hands.
Fixes: my $i := 1 if False; $_ with $i		 08:15
nine 1266 bootstrapped
Geth rakudo/main: cca6be6649 | (Stefan Seifert)++ | 2 files
RakuAST: fix public attribute accessors swallowing call chains

While a shorthand method call like $.foo may take arguments, we accidentally cut down a whole call chain like $.foo()()(1) and passed the last arg list to foo. Fix by ensuring that we only move arguments once.
Fixes: $.foo()(1)		 08:46
nine 1267
lizmat [Coke]: did you do a blin run already? 09:36
Geth rakudo/main: fc4811a235 | MasterDuke17++ (committed using GitHub Web editor) | src/core.c/Mu.rakumod
Add variable name if possible to warning about use of uninitialized numeric
 10:44
lizmat m: my %h; dd %h.of; %h<a>.push(42); dd %h # all is well 10:45
camelia Mu
{:a($[42])}
lizmat m: my M %h; dd %h.of; %h<a>.push(42); dd %h # huh 10:46
camelia ===SORRY!===
Type 'M' is not declared
at <tmp>:1
------> my M<HERE> %h; dd %h.of; %h<a>.push(42); dd %h
Malformed my
at <tmp>:1
------> my<HERE> M %h; dd %h.of; %h<a>.push(42); dd %h
lizmat m: my Mu %h; dd %h.of; %h<a>.push(42); dd %h # huh
camelia Mu
No such method 'push' for invocant of type 'Mu'. Did you mean 'put'?
in block <unit> at <tmp> line 1
JimmyZhuo nine: re 9f58a3420e978acd3f001236c31caf481fc63e98 regressed t/spec/S12-attributes/class.t: 'my $package := $!package.meta-object;' in PERFORM-CHEC causes "No such method 'z-thunk' for invocant of type 'RT130748d'" error, I don't know why 10:48
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)
tellable6 2025-03-18T15:43:20Z #raku-dev <nine> JimmyZhuo: somehow commit 9f58a3420e978acd3f001236c31caf481fc63e98 regressed t/spec/S12-attributes/class.t
JimmyZhuo *PERFORM-CHECK 10:49
lizmat m: my %h; use nqp; dd nqp::getattr(%h,Hash,q/$!descriptor/).default 10:51
camelia Any
lizmat m: my Mu %h; use nqp; dd nqp::getattr(%h,Hash,q/$!descriptor/).default
camelia Mu
lizmat the underlying difference
nine JimmyZhuo: almost all strange RakuAST problems are because of timing. If you call $!package.meta-object, that will end up calling PRODUCE-META-OBJECT in RakuAST::Package. I guess that when the PERFORM-CHECK runs that package is not yet ready for getting composed, i.e. the methods have not been added yet. 10:52
I usually debug this by adding an nqp::cluckfull to both the PRODUCE-META-OBJECT and that PERFORM-CHECK method and see the difference with and without the meta-object call 10:53
JimmyZhuo cluckfull? I never see this op 10:55
nine It's from my NQP debug helpers: gist.github.com/niner/717890812dd1...90ac6e4737
Apply that patch to your NQP to get nqp::note, nqp::cluck and nqp::cluckfull 10:56
JimmyZhuo thanks, I will give it a try 10:57
nine: from the error msg, seems it's a runtime error. 10:59
releasable6 Next release in ≈3 days and ≈7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
nine JimmyZhuo: yes it is a runtime error. But it's caused because that class does not have any methods.
Normal flow is: we create the class meta object stub as soon as we encounter the { in class Foo {. Then we parse the methods which as a BEGIN time effect add themselves to the class. When we reach the class' } we finish building the meta object (by calling $meta-object.HOW.compose($meta-object)). 11:02
If you call $!package.meta-object before we even have reached that } the class will remain incomplete. No more methods will get added.
That's why there's also a .stubbed-meta-object accessor. This gives you the type object without trying to compose it first. Obviously that type object will not have all the information yet. 11:03
But it's good enough for straight forward type checks
JimmyZhuo a lot of things runs before CHECK TIME, I thought the IMPL-QAST-XXXX always run after CHECK TIME, but it's not for role 11:05
nine BEGIN time calls make everything extremely hard. And when you do class Foo does Bar { } this runs Bar's body at compile time 11:07
lizmat: fun fact: github.com/rakudo/rakudo/commit/de...1c39ba4e03 works only because of a bug in the optimizer 11:10
lizmat you mean "is raw" should be added ? 11:11
nine I think is rw but both probably do the same 11:13
lizmat ok, will do
nine It also would not work without the optimizer
JimmyZhuo the most hard one is making it fast ;) 11:14
I think it will be easier with RAKUAST? 11:16
nine That's the hope 11:17
JimmyZhuo make 11:25
+++ Compilingblib/Perl6/BOOTSTRAP/v6c.moarvm
Unknown QAST node type NQPMu
at NQP::src/vm/moar/QAST/QASTCompilerMAST.nqp:2115 (/home/jimmyz/nqp/../moarvm/install/share/nqp/lib/QAST.moarvm:compile_node)
from NQP::src/vm/moar/QAST/QASTCompilerMAST.nqp:645 (/home/jimmyz/nqp/../moarvm/install/share/nqp/lib/QAST.moarvm:as_mast)
after adding nqp::cluckfull(); 11:26
nine Needs a message: nqp::cluckfull('here');
JimmyZhuo works now, it's LTA error 11:27
Geth rakudo/main: 19f77e302a | (Elizabeth Mattijsen)++ | 2 files
Make sure that .head/first/head() on natives are "raw"

They apparently *do* need that, and the only reason this worked so far, is because of a bug in that (legacy) static optimizer.
  nine++ for spotting		 11:48
Geth rakudo/main: bc05703131 | (Elizabeth Mattijsen)++ | 3 files
Expand Hash parameterization

This allows one to specify a default value for any containers as well. By default, this is the same as the "of" type, as it was before.
So the standard hash "parameterization" is now Hash[Mu,Str(Any),Any] ... (8 more lines)		 13:04
[Coke] blin run started - haven't yet figured out what was skipping Red, so it will fail pre/post again, apologies. 13:05
SmokeMachine [Coke]: thanks for letting me know, I'll test Red on Rakudo's `main` branch locally then, thanks 13:07
[Coke] c: bc05703131b667160808974f99fd8b3546fa2607 13:17
committable6 [Coke], I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Committable
[Coke] c: bc05703131b667160808974f99fd8b3546fa2607 say 3 13:18
committable6 [Coke], ¦bc05703: «3␤»
[Coke] blin exploded after a minute, bad timing on that commit, but it looks OK now? 13:19
lizmat bc05703131 should not make a difference for non-RakuAST related stuff
linkable6 (2025-03-19) github.com/rakudo/rakudo/commit/bc05703131 Expand Hash parameterization
lizmat the two failing spec tests *are* RakuAST related because of the new .assuming implementation 13:20
and I'm not sure yet whether that needs a fix in the test, or in the new .assuming logic 13:21
Geth roast: 0e3a65e3cd | (Stefan Seifert)++ | S06-advanced/return.t
Fix test for return in parameter defaults and skip it

According to the linked issue, parameter default thunks are supposed to run inside the routine body they're attached to. Thus a return in such a thunk would be caught by the return handler of this routine.
The test for this however relied on the return handler of the ... (8 more lines)		 13:36
rakudo/main: 7b4ba29c3f | (Stefan Seifert)++ | 2 files
RakuAST: only generate return handlers when there's a chance of explicit return

Routines only need a return handler if it's actually possible that an explicit return is performed. Unfortunately finding out with certainty whether that's the case is impossible because there are many ways of calling return including method calls and from EVALed strings. Thus we need to be prudent and add the handler if there's even a possibility ... (7 more lines)		 13:37
rakudo/main: 57fcb1f1b0 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: dont' decont return values of rw routines

Routines that are rw or raw are meant to return a container or lexref that can be written to. Thus deconting would be counter productive.
nine 1269 13:38
[Coke] Anything tagged RakuAST in the commit only matters (right now) when the env var is enabled, right? 13:52
(so those are safe as "last minute" commits to the release) 13:53
nine Usually yes 13:54
nine m: class Foo { has @.command is List }; my @command = [1, 2]; dd Foo.new(:@command) 13:55
camelia Foo.new(command => (1, 2))
nine When you disable generate_buildplan_executor, this ^^^ prints Foo.new(command => ())
lizmat m: class Foo { has @.command is List }; use BUILDPLAN Foo 14:00
camelia class Foo BUILDPLAN:
0 nqp::getattr(obj,Foo,'@!command') := initializer-code()
1 nqp::getattr(obj,Foo,'@!command') = :$command if possible
lizmat m: class Foo { has @.command }; use BUILDPLAN Foo 14:01
camelia class Foo BUILDPLAN:
0 nqp::getattr(obj,Foo,'@!command') = :$command if possible
1 vivify nqp::getattr(obj,Foo,'@!command') if part of a mixin
lizmat quite possibly the initializer code is turning the @.command into a List before it's getting assigned ? 14:02
nine: I propose getting rid of the buildplan logic as soon as possible, instead of trying to fix it in RakuAST 14:03
nine Well for now I consider this problem out of scope for RakuAST. 14:05
lizmat indeed, and it is, and we can fix it in RakuAST :)
nine Can we? 14:06
I'm not actually sure what difference RakuAST makes to this 14:07
lizmat because we can pass the right args to @.command.STORE to make it work on what is essentially a list 14:09
inside the POPULATE sub that we generate 14:10
nine Why can we not do that with the old frontend?
lizmat *method
we could, but why would we at this point ?
nine Why did we keep Mu.BUILDPLAN for so long? 14:11
lizmat because NQP?
nine ? 14:12
Last I checked, NQP still exists, so I clearly don't understand that answer :)
lizmat yeah, I was wrong: I thought NQP also had a BUILDPLAN logic 14:13
so to answer your question: because nobody tried to get rid of it ?
actually, I just checked: the current logic *should* allow it? 14:14
m: class A { has @.foo is List }; dd A.new(foo => (1,2,3)).foo 14:15
camelia (1, 2, 3)
lizmat m: class A { has @.foo }; dd A.new(foo => (1,2,3)).foo
camelia [1, 2, 3]
lizmat so is already handled correctly ?
so I guess I don't understand your point about disabling generate_buildplan_executor ? 14:16
nine It only works on the old frontend because of generate_buildplan_executor. The bug is in Mu.POPULATE
lizmat ok, I'm not sure what the bug is now ?
if there's a bug in Mu.POPULATE, it's been there for at least 5 years, if not longer 14:17
nine It is there and yes, likely for that long 14:18
lizmat but what is the bug?
nine > ./rakudo-m -e 'class Foo { has @.command is List }; my @command = [1, 2]; dd Foo.new(:@command)'
Foo.new(command => ())
lizmat m: class Foo { has @.command is List }; my @command = [1, 2]; dd Foo.new(:@command)
nine Clearly wrong, isn't it?
camelia Foo.new(command => (1, 2))
lizmat yes
so the bug is in the bootstrapped RakuAST version ? 14:19
that has the generate_buildplan_executor disiabled?
I'm not surprised then ?
nine No, the bug is in POPULATE. It just so happens that RakuAST does not have a buildplan executor generator, so it always uses POPULATE
But if you disable the generator in the old frontend, you see the bug there as well. So it's got nothing to do with RakuAST per se. 14:20
lizmat I see... /me checks
[Coke] ⏳ 252 out of 2296 modules processed (10.97%) 14:22
ah, when I see "attempting to fetch" mid blin run, it's bisecting. duh 14:24
lizmat ok, looks like the Mu::POPULATE does not call .STORE for array inits 14:25
nine: I *think* that's because of bootstrapping issues, because the method .STORE may not yet exist
nine Wouldn't everything that's compiled in the setting get a generated executor? 14:26
lizmat no, not until some point during the bootstrap when compiler services become a thing ? 14:27
lizmat which is after the Attribute class is compiled ? 14:28
and attribute.compose exists ?
nine Ah, indeed, there's a try block 14:31
lizmat still, only class Mu and class Any precede that,
still, I'd rather spend time on getting a RakuAST based POPULATE method, then trying to fix this in the old backend at this point 14:34
with it, all BUILDPLAN generator logic / Mu::POPULATE and compiler services, can be eradicated 14:35
nine There's still gonna be the bootstrapping issue and the case where a class is purely generated via MOP at runtime 14:47
lizmat yeah, this is why I'm not sure where to feed the POPULATE logic from: from the RAKUAST tree info? Or from the generated meta-object? 14:48
if it were to be from the generated meta-object, the MOP case could be covered as well 14:49
nine: what do you think ? 14:52
nine Feeding from generated meta-object is not enough. The MOP would still need access to the compiler 14:53
After all, the whole point of CompilerServices is to give the MOP access to the compiler
lizmat but basically just for COMPOSE phaser functionality? or am I missing something? 14:54
nine huh? 14:55
lizmat basicallly, generating any accessors that should be created, and the POPULATE method ?
nine Well, yes, that's what CompilerServices is used for 14:57
lizmat there are no other uses, right? there aren't afaik
nine right 14:58
lizmat my original plan was to generate the accessors and POPULATE before CHECK time
building classes with the MOP sorta clashes with that idea ;-) 14:59
nine that's my point
lizmat but we already have the meta-object just before CHECK time, right ? 15:00
so we conceptually could generate accessors and POPULATE, and in the case of MOP created classes, put them into a role and mix them in ? 15:02
nine Why would we need a role when we're in the metaclass' compose method where we can just add stuff as we like? 15:06
lizmat so you'd want to call .EVAL on each generated component ? 15:07
nine what? 15:08
lizmat each generated accessor method, and the POPULATE method 15:13
nine How does EVAL enter the picture? 15:14
lizmat .EVAL on the created RakuAST tree ?
nine We're talking about generating a bunch of methods and adding it to the class
lizmat for the MOP case
we don't have a RakuAST for the MOP case, do we ? 15:15
nine If you don't have a RakuAST then how would you call .EVAL on it?
And anyway EVAL would just be a very roundabout way to call into the compiler
lizmat I have to go afk now, for a few hours 15:16
I'll get back to it, ok ?
nine k 15:17
lizmat afk&
lizmat rakkable: eco-pr ^* 17:38
rakkable lizmat, Running: eco-provides ^*, please be patient!
lizmat, Found 117 lines in 25 files (25 distributions):
lizmat, gist.github.com/eb95839bd01a9f4ef6...67248d1bf9
[Coke] ⏳ 1020 out of 2296 modules processed (44.42%) 17:39
lizmat rakkable: eco-pr ^* --type=contains
rakkable lizmat, Running: eco-provides ^* --type=contains, please be patient!
lizmat, Found 117 lines in 25 files (25 distributions):
lizmat, gist.github.com/7f174e08a5a6d90c5f...77c0751174
lizmat meh
Geth rakudo/main: 90d8e011da | (Stefan Seifert)++ | src/Raku/ast/statementprefixes.rakumod
RakuAST: only optimize to SUPPLY-ONE-WHENEVER in v6.d and above

The setting itself is language version 6.c and SUPPLY-ONE-WHENEVER is only available from 6.d onwards. Using it would lead to strange errors because dynamic variables are not found.		 17:51
rakudo/main: 1d32d9020d | (Stefan Seifert)++ | 4 files
RakuAST: fix detecting number of whenevers in a supply

The previously used logic to detect whether a supply has a single whenever was inadequate to the complexities of Raku code. It only detected the straight forward cases of multiple whenever statements directly in the supply block or one whenever directly in the block of another whenever. There are however constructs like: ... (5 more lines)
nine We're at 1270 fully bootstrapped
Geth rakudo/bootstrap-rakuast: 29 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/a...5cb9e33783		 18:10
nine 1271
m: sub foo(int $tz) { }; foo($*TZ) 18:39
camelia Cannot auto-decontainerize argument
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
nine So I had this super nice golf of the problem. I thought I had a fix for it. Then it turns out, the golf fails exactly the same way in the old frontend. 18:41
Now I'm back to finding out what in the 10 layer callstack makes the problem go away in the old frontend :/
m: sub foo(int $tz) { }; sub bar(Int(Cool) $tz) { foo($tz) }; bar($*TZ) # the better golf 18:49
camelia ( no output )
Geth rakudo/main: bcff40fc5f | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: ensure we decont the result of parameter coercion

During parameter processing we set up a local variable for the parameter and also a deconted one. In some cases like with coercive parameter types we use that deconted value and produce yet another value. In the compiler code we then clear $get-decont-var to signify that it no longer refers to the most current version of the parameter value (that would be ... (8 more lines)		 19:09
nine 1272
[Coke] I really feel like Blin got faster on this box without me doing anything 19:26
I wonder if I'm just getting more resources from azure just by luck. 19:27
I don't remember happening to see Device::Velleman::K8055 before 20:14
⏳ 1666 out of 2296 modules processed (72.56%) 20:56
one of the packages is "SparrowCI - super fun and flexible CI system with many programming languages support" 20:58
which I can search for on raku.land but not get a useful page out of.
looks like zef is reporting on 0.0.2, but the 0.0.12 in the repo has that in the description, not the name. 21:00
(guessing something else depends on that old name) 21:01
... or we need a way to delete old stuff.
Geth rakudo/main: c6e150a7e0 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix defined subset types not checked in dispatch

While we did emit code for checking subset types, we did not do so if the subset type was augmented with a definedness-constraint.
Fixes: multi foo(UInt:D $i) { }; foo(-1) # To fail		 21:34
nine 1273
patrickb Do we currently or have we ever supported clang on Windows? 21:43
Geth rakudo/main: 9fe52a1d58 | (Elizabeth Mattijsen)++ | 2 files
Make sure Hash/::Typed/::Object take same parameterization

Not entirely sure exactly what is going on here, but .assuming got confused by the fact that Hash::Typed only took 2 paremeterization arguments, and Hash and Hash::Object take 3.
Code should just use the Hash[...] parameterization. But internally ... (16 more lines)		 21:59
lizmat rakkable: eco-pr --pattern=^* 22:06
rakkable lizmat, '--pattern' argument not allowed / unknown: ignored
lizmat, Running: eco-provides , please be patient!
lizmat, Found 9937 lines in 64 files (11 distributions):
lizmat, gist.github.com/3a638aa4b918f2d5e0...928adb404f
Geth rakudo/bootstrap-rakuast: 30 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/d...0f03a9cbce		 22:09
nine And that's 1273
1274
All remaining additional failures are .assuming related (except for the BUILDALL thing we discussed today), so I consider them out of scope.
Thus bootstrap is complete from my perspective! 22:10
lizmat Nice! 22:11
so what's the next step in your opinion: I guess it's too early to merge the bootstrap, right? 22:12
because that would set us back from 1345 -> 1274 passing 22:13
and defnitely not now so close to the 2025.03 release
afk again& 22:18
[Coke] ⏳ 1862 out of 2296 modules processed (81.09%) 22:41

Powered by Cro and the Raku® Programming Language.

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

Thank you!