🦋 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.
lizmat nine: I think I found the general area where this needs changes... will look at it in the morning 00:46
finanalyst I'm trying to create a docker container using croservices/cro-http-web. I'm getting errors. Are the links bad on docker hub? 07:53
lizmat I haz no idea 09:53
nine: gist.github.com/lizmat/47db42f1064...ce901602ee feels that it should be the fix for the T @b issue, but isn't :-( 09:54
nine Shouldn't you make it use the full binder instead? 09:58
lizmat probably, but am at a loss to make it do that? 10:03
I was merely going by code similarity, not grokking the bigger view 10:04
nine look for needs-full-binder 10:05
lizmat looks 10:07
Geth rakudo/main: 49da3628d1 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix accessing implicit %_ in methods

The placeholder parameter will be added to the method before the signature gets its BEGIN time, so the IMPL-HAS-PARAMETER check will fail. Luckily we *know* that methods get a %_.
Fixes: method foo() { dd %_ }		 10:20
lizmat nine: updated gist, copied code from the full-binder handling 10:33
changes the error to "Method T.ACCEPTS not found" instead of inconsistent bind result
nine No, the point is to not generate any signature lowering code at all in this case. You need to detect this situation early enough so :needs-full-binder gets passed to IMPL-QAST-BINDINGS 10:41
lizmat ack 10:48
JimmyZhuo Cannot put required parameter $b after optional parameters 11:30
at -e:1
------> sub wrong2 ($a = 1, $b<HERE>) {...}
expecting any of:
constraint
E:\OpenSource\Rakudo>rakudo-m -e "sub wrong2 ($a = 1, $b) {...}"
===SORRY!=== Error while compiling -e
Cannot put required parameter $b after optional parameters
at -e:1
------> sub wrong2 ($a = 1, $b<HERE>) {...}
expecting any of:
constraint
How to get the "------> sub wrong2 ($a = 1, $b<HERE>) {...}" infomation in RAKU AST?
seems the check is moved from action to "PERFORM-CHECK" 11:31
lizmat nine: gist updated, the error is changed, but is this the right approach? 11:34
nine The point was more to get $needs-full-binder passed to IMPL-QAST-BINDINGS in the first place, so it doesn't have to check anything else anymore 11:53
JimmyZhuo: yes, a PERFORM-CHECK method needs to detect this condition before we even generate QAST. Most likely on RakuAST::Signature 11:55
lizmat nine: understood 11:56
Geth rakudo/main: 3a6c59c0ce | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod
Backport RakuAST::Utils fixes to core

  - Fixes handling of generics in .assuming if they are not curried		 12:37
nine I wonder why those use string comparisons instead of proper type checks 12:45
lizmat I wanted to make sure they won't break once we start working on Raku/Metamodel/Foo ? 12:51
meanwhile, I got the fix for ::T handling, spectesting now 12:53
meh.... breaks a number of other tests :-( 13:00
nine: gist updated, do you see anything obviously wrong 13:02
?
nine: realized the reason why checks on names 13:07
m: dd Perl6::Metamodel::ParametricRoleGroupHOW
camelia Could not find symbol '&ParametricRoleGroupHOW' in 'GLOBAL::Perl6::Metamodel'
in block <unit> at <tmp> line 1
Geth rakudo/main: 7cba23e34d | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: simplify Call::Method code for qualified calls

No need to do all that string manipulation business just to end up with non-standard name structures.		 13:08
lizmat m: dd Perl6::Metamodel::CoercionHOW
camelia Could not find symbol '&CoercionHOW' in 'GLOBAL::Perl6::Metamodel'
in block <unit> at <tmp> line 1
nine m: Metamoel::CoercionHOW
camelia Could not find symbol '&CoercionHOW' in 'GLOBAL::Metamoel'
in block <unit> at <tmp> line 1
nine m: Metamodel::CoercionHOW
camelia WARNINGS for <tmp>:
Useless use of constant value Metamodel::CoercionHOW in sink context (line 1)
lizmat ah?
hmmm...
nine It's just called differently in user space code 13:09
lizmat TIL
nine Outside Perl6::ModuleLoader there's no good reason for comparing type names
lizmat ack
nine Even if we want to rename those types at some point (and it'd just be rather pointless cosmetics) it's just a perl -p -i -e 's/Perl6::Metamodel/Raku::Metamodel/g' on the whole codebase anyway 13:10
Ironically the only cases that this wouldn't catch *are* the ones where people do some string manipulation business with names 13:11
lizmat understood :-) 13:12
nine: see anything obviously wrong with the updated gist ? 13:15
nine lizmat: no looks fine. I'm a bit surprised though. Does our lowered code really not support any parametric types at all? 13:17
lizmat well, I was just following Timo's lead on the fix 13:18
for the legacy grammar
Timo's judgement was that it did not support parametric types for that case anyway 13:19
m: :(::T $a, T @b)
camelia ( no output )
nine I'd be extremely surprised if we didn't support e.g. sub foo(int @a) 13:19
lizmat note that :(::T $a, T $b) was find 13:20
*fine
but things turn for the worse with :(::T $a, T @b, T %c)
aka, generically typed non-scalars 13:21
nine That's not what the gist is checking for though 13:22
Look at the context in which the original code is placed: github.com/rakudo/rakudo/commit/0bcab7a86f 13:23
lizmat it's checking whether the parameter is parametric 13:24
that's what the gist also does, no ? 13:25
nine in what context?
lizmat ah, you mean: $is_generic && !$is_coercive ? 13:26
nine The comment says "Parametric types that are generic" the commit message says "with parametric generic types" and 2 lines above that code is an "if $is_generic && !$is_coercive"
lizmat right
nine At least this is a great show case for why it sucks having to port fixes from one branch to the other when the author of the original didn't bother. 13:27
lizmat perhaps, but I'm glad for all fixes, great or small or incomplete 13:29
nine I'm not. I need to get this RakuAST thing done. Everything that makes it take longer just hurts. 13:31
Geth rakudo/main: aff6eaf3e2 | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod
Use proper typechecks in .assuming logic

  nine++ for the nudge		 13:32
nine What's the point of an "is default(Nil)" in a variable that's immediately initialized anyway? my $old-handle is default(Nil) = $!active-handle 13:38
lizmat m: my $a is default(Nil) = 42; $a = Nil; say $a 13:39
camelia Nil
lizmat it might get Nil assigned later, and then needs to produce Nil instead of the default "Any" (if no "is default" was specified) 13:40
Geth rakudo/main: 15e4299ab1 | (Elizabeth Mattijsen)++ | src/Raku/ast/signature.rakumod
RakuAST: provide ::T $a, T @a fix

Basically the RakuAST equivalent of 0bcab7a86f. Nine++ for guidance		 13:45
roast: 4d8ee0422f | (Elizabeth Mattijsen)++ | S06-currying/misc.t
Add test for :(::T $a, T @b) handling
 13:46
roast: 44594f7309 | (Elizabeth Mattijsen)++ | S06-currying/misc.t
Add some more currying tests
 13:57
lizmat nine: ^^ yes, they pass on RakuAST :-)
afk for a few hours& 14:01
timo i didn't know rakuast had an equivalent to the lowerer 14:33
nine Why wouldn't it? 14:34
Everything from Perl6/World and Perl6/Actions has to go somewhere
timo lowering of signature binding could potentially have been postponed since it's kind of an optimization more than something that gets more tests to run. though priorities don't usually work rigidly like that 14:49
we don't have anything in place to alert us if newly written tests fail with rakuast on, right? 14:50
nine no 14:52
timo only that it explodes when your "make spectest" pulls fresh tests and you have to wonder why the failures went up 15:00
do you have something like a "good first issue" for me to look at in terms of RakuAST right now? 15:01
nine irclogs.raku.org/raku-dev/2025-03-07.html#11:09 15:02
timo cool thanks 15:09
lizmat m: BEGIN my &a = &max.assuming(42) 17:25
camelia ( no output )
lizmat looking at the QAST of ^^ I am surprised I see QAST generated for the &max.assuming(42) part 17:26
I sorta expected to just see a WVAL for the sub, with all of the QAST needed to create the sub discarded 17:27
nine That BEGIN block may contain nested blocks that need to survive 17:37
Geth rakudo/main: e2ec3a2d09 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: support multiple slurpy parameters on routines

Fixes: sub foo(**@a, |c) { }		 17:38
timo is the optimizer able to throw these out? if not, probably not a good time to put that in, what with rakuast being around the corner 17:40
lizmat yeah, indeed.... :-)
don't spend time on that :-)
Geth rakudo/main: d6d385952a | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: use low level ops for assignment
 19:49
rakudo/main: 1132925ea4 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: move check for multiple slurpies to BEGIN time

CHECK may not have been performed when we generate QAST at BEGIN time, e.g. for role bodies.
rakudo/main: 1fd7db7f48 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix using declarations of native variables as expressions

Fixes: (my str $a, my str $b) = "a:b".split: ":"
nine 1272 (despite not even working on spectests)
Geth rakudo: MasterDuke17++ created pull request #5806:
RakuAST: throw correct exception for disallowed adverbs when augmenting		 20:55
rakudo/main: 672126d45b | (Daniel Green)++ | src/Raku/ast/package.rakumod
RakuAST: throw correct exception for disallowed adverbs when augmenting
 21:26
rakudo/main: 0fb4b32a60 | niner++ (committed using GitHub Web editor) | src/Raku/ast/package.rakumod
Merge pull request #5806 from MasterDuke17/throw_correct_exception_when_using_disallowed_adverbs_when_augmenting

RakuAST: throw correct exception for disallowed adverbs when augmenting

Powered by Cro and the Raku® Programming Language.

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

Thank you!