🦋 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 +++ Installing files 02:43
Cannot find method 'unshift' on object of type BOOTArray
at src\Perl6\Metamodel\C3MRO.nqp:64 (E:\OpenSource\Rakudo\blib/Perl6/Metamodel.moarvm:compute_mro)
today I can't make install, and yesterday is ok 02:44
JimmyZhuo It's my problem, after restart the windows and it's ok now 03:11
Geth rakudo/main: 3b020e9cf5 | (Stefan Seifert)++ | 2 files
RakuAST: prohibit colonpairs on package names (except ver/api/auth)
 07:41
nine 1262
Geth rakudo/main: a343c41469 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: support is hidden trait on packages
 07:45
nine 1263
Geth rakudo/main: e84e7a94dc | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: fix being unable to resolve ::?PACKAGE
 08:15
rakudo/main: ac06d7bec7 | (Stefan Seifert)++ | 2 files
RakuAST: support explicitly declaring package in GLOBAL

Fixes: module Foo { class GLOBAL::Bar { } }
nine 1264
Geth rakudo/main: d9b7d43bd0 | (Stefan Seifert)++ | 3 files
RakuAST: support args on public attribute shorthand accessor notation

Fixes: $.foo(1)		 08:34
nine 1267!
patrickb nine: Nice you got it to work! I'm unsure if this applies to this specific case, but in general, I prefer for Raku to have clear and comprehensible limits instead of borders being pushed in places, making it basically impossible for the user to know in advance what's possible and what isn't. 08:37
Two weeks ago or so I wondered who'd be first, You with finishing with RAST or I getting a first prototype of the TUI debugger running. But I guess that's a settled question. I'm not at all unhappy about that. 😊 08:40
nine Well we don't know what may still be lurking in those remaining tests. And then there's the bootstrap 08:44
patrickb I guess paying the bootstrap due respect makes sense... 08:46
But then I'm currently having a hard time getting that **** PTY running on Windows... 08:47
nine You're probably just the latest in a long list of engineers with such a problem. UNIX ttys are a hell born of a 100 years of history from the dark ages of computing, but with Windows they didn't even seem to try. 08:54
patrickb There is native Windows support since recently. ConPTY it's called. In principle it's pretty trivial to use. I just currently fail to get it working in libuv. But I believe it's a pretty solvable issue. I've probably just approached the problem wrong. (Instead of working up from a minimal working example, I tried getting it running directly in the full Rakudo stack with T-W and a Raku 09:09
terminal emulator sitting on top.)
nine Ah yeah, that detour via a minimal example might pay off in this case :) Have fallen into that trap a lot of times myself 09:10
patrickb It's not like I should have learned this by now after more than a decade in IT. 😝 09:10
Geth rakudo/main: 0494de12b6 | (Stefan Seifert)++ | src/Raku/ast/type.rakumod
RakuAST: use runtime lookup when accessing package stubs

Any package stub we access might get replaced by an actual package later, so we need to defer settling on the actual value until runtime.
Fixes: class X::Y::Z { }; my \x = X::Y; class X::Y {}; x.new		 10:31
nine 1268
JimmyZhuo nine++, 77 left 10:49
nine Thanks! I still would ejoy patches more than cheering btw. I intentionally skipped several spec test files that only lament missing compile time checks. Those are usually quite simple to add. Just look at the --target=ast output of the offending code and add some PERFORM-CHECK code to the appropriate node that checks whether its children fit that pattern and add-sorry the appropriate exception. There's 11:09
plenty of examples already. 11:10
lizmat do you have an example commit that people could look at, that shows that process ?
JimmyZhuo github.com/rakudo/rakudo/commit/3d...5eeadfb796 this? 11:14
nine 3b020e9cf51cd431af21640e6f6d223c4ea19df9 3d651c2ef09b2577cfcccf9a28596b5eeadfb796 6084eb2ff259852543e385c7f39516e5547f108e ad746c66d7d9f60a337b4623ee375c58614100a4 b8ae70efba5962612900f00443fae5d4e6eafe3a
linkable6 (2025-03-07) github.com/rakudo/rakudo/commit/3b020e9cf5 RakuAST: prohibit colonpairs on package names (except ver/api/auth)
(2025-03-05) github.com/rakudo/rakudo/commit/6084eb2ff2 RakuAST: report invalid attribute access in subsets
(2025-02-28) github.com/rakudo/rakudo/commit/b8ae70efba RakuAST: prohibit clashing of parameter names
lizmat thanks!
nine t/spec/S06-signature/optional.t t/spec/S06-signature/positional-placeholders.t t/spec/S06-signature/slurpy-params.t t/spec/S06-traits/misc.rakudo.moar t/spec/S06-traits/native-is-rw.t t/spec/S09-typed-arrays/native-num.rakudo.moar t/spec/S12-attributes/inheritance.t t/spec/S12-attributes/undeclared.t t/spec/S12-attributes/smiley.t t/spec/S12-class/open.t 11:15
Geth rakudo/main: 19c4cfefcd | (Stefan Seifert)++ | 2 files
RakuAST: complain about package stubs that were never replaced

Fixes: class Foo { ... } # to die		 12:36
nine 1269
Ok, this one sucked. As packagy stuff tends to do
Geth rakudo/main: 8a5a40e1b3 | (Stefan Seifert)++ | src/Raku/ast/type.rakumod
RakuAST: ensure we always have a base type for enums

Fixes: my enum Foo(1..2) # which got confused by the Range		 13:38
rakudo/main: e76deb895c | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: use compile time initializer values directly for attribute's build
nine 1270
lizmat m: sub a(::T $a, T @b) { dd :$a:@b }; a 42, my Int @ = 42 # somehow, an .assuming test for this passes, probably because it doesn't do proper typechecking 13:49
camelia Internal error: inconsistent bind result
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
timo "inconsistent bind result" sounds like the binding lowering code is making a boo-boo? that code is supposed to be correct, right? 13:56
"inconsistent bind result" could mean the fast-path / lowered binder says it's wrong, then the full binder runs in order to generate a good error message and decides that it's actually correct 13:57
Geth rakudo/main: 812c7ec783 | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: turn :ver attributes into Version objects on package names
 13:59
nine 1271
timo 00021 const_s loc_4_str, 'Positional[T]' 14:46
00022 getlexperinvtype_o loc_9_obj, loc_4_str
00023 istype loc_8_int, loc_11_obj, loc_9_obj
well, that doesn't seem like it's going to work :)
the code binds to lexical "T" a little further up though 14:47
and yes, this is the code the binding lowerer has generated
hrmpf. stepping with the moar remote is still not fully reliable 15:23
the qast that comes out of the lowerer has QAST::Var(typevar Positional[T]) for the type of the second parameter, so I wonder what exactly has to happen for the whole thing to work 15:31
the next thing the lowerer generates is the code for handling coercive types (since it doesn't know if Positional[T] will result in a coercive type or not) 15:34
probably not actually relevant 15:36
there's some handling for @ and % sigiled parameters further below, maybe the type check wants to steal a bit from that part (or delegate / defer to it) 15:37
maybe we should look if there's a lexical in the block with the name of the typevar and if not just bail out of lowering. it will be "slower" but at least it won't throw an exception :)
liztormato timo: will look at it further when back from cycling 15:43
timo i'm writing code to bail out if we have the case in question for now 15:46
ok, no exception from the code yet 15:53
i think it's preventing lowering in places that did use to lower, so i need to go check on that 15:56
hrmpf. this doesn't deal with type parameters of an enclosing role for example 16:00
m: role R[::TValue] { method ah(TValue @foo) { dd; dd :@foo } }; R[42].ah(my Int @ = 1); 16:01
camelia Internal error: inconsistent bind result
in method ah at <tmp> line 1
in block <unit> at <tmp> line 1
timo so the check for "does the block have it as a lexical" isn't good anyway
m: role R[TValue] { method ah(TValue @foo) { dd; dd :@foo } }; R[Int].ah(my Int @ = 1); 16:02
camelia ===SORRY!=== Error while compiling <tmp>
Invalid typename 'TValue' in parameter declaration.
at <tmp>:1
------> role R[TValue<HERE>] { method ah(TValue @foo) { dd; dd :@fo
timo maybe we can ask $*W at that point
i found a sub typevar_or_lexical_lookup that i can steal from :3 16:06
liztormato timo: have you checked whether it works with RakuAST? 16:08
timo i have not
it's RAKUDO_USE_RAKUAST=1 right?
liztormato I haven’t yet 16:09
Yes
timo m: Q[[[ role R[::TValue] { method ah(TValue @foo) { dd; dd :@foo } }; R[Int].ah(my Int @ = 1); ]]].AST.eval()
camelia MoarVM panic: Memory allocation failed; could not allocate 131072 bytes
timo uhhhhhhh
[Coke] wonders why liztormato's text is invisible. 16:10
liztormato I can see mine. ;-)
[Coke] (until their most recent send)
liztormato timo: .EVAL
[Coke] 3 sends before that were black on black text here. 16:11
timo m: Q[[[ role R[::TValue] { method ah(TValue @foo) { dd; dd :@foo } }; R[Int].ah(my Int @ = 1); ]]].EVAL
camelia Internal error: inconsistent bind result
in method ah at EVAL_0 line 1
in block <unit> at EVAL_0 line 1
in block <unit> at <tmp> line 1
[Coke] ^^ like that one.
don't see any weird colorings in the logs.
timo i see the colors too 16:13
maybe it should just bail based on archetypes generic + parametric 16:19
liztormato I’m not sure it should bail 16:22
timo why not?
liztormato I think it’s valid code? 16:24
timo yeah it is. so the lowerer shouldn't spit out the wrong optimized code for it 16:25
m: sub a(::T $a, Positional[T] $b) { dd :$a:$b }; a 42, my Int @ = 42
camelia Internal error: inconsistent bind result
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
timo a little surprised we don't seem to have any spec tests for this 16:26
or maybe all the spec tests that have this in them also have something else that already makes the lowerer bail out
liztormato Well. There is an .assuming test for it that failed with my new code. But which incorrectly succeeded with the current assuming code 16:29
That’s how I found this issue 16:30
timo right
something like "parameters with types that are parametrizations with a captured type" seems like something we should have stand-alone tests for though 16:31
liztormato Agree 16:32
Afk for an hour or so 16:34
Geth rakudo/dont_lower_generic_parametric_params: 727d0ee96a | (Timo Paulssen)++ | src/Perl6/Actions.nqp
Don't try to lower signatures with parametric generic types

Fixes "inconsistent bind result" for signatures with a type capture followed by @ or % sigiled params using the typevar, or when such a param uses a type capture param of a role.		 16:36
rakudo: timo++ created pull request #5804:
Don't try to lower signatures with parametric generic types		 16:39
nine lizmat: I'm curious. What was the plan for making method literalize work with bootstrap? 18:15
lizmat crossing that bridge when we get to it ? 18:20
nine Do you realize that that means a guaranteed rewrite of the whole thing? 18:22
lizmat looks at the code 18:23
why would a rewrite be needed? we have all of RakuAST at the start of the bootstrap, don't we ? 18:24
nine Actually at the end of bootstrap. But that does not include src/core.c/RakuAST/Literalize.rakumod 18:27
timo is blissfully unaware of all that 18:28
lizmat is confused now 18:31
nine why? 18:32
lizmat in Raku/ast there are a few calls to .literalize in ast/name.rakumod
the multi methods in src/core.c/Literalize.rakumod live there for convenience
they could all be written in the Raku bootstrap 18:33
nine And they should have been
lizmat why? most of them won't be needed in the bootstrap?
nine When bootstrapping we won't even find .literalize at all as it's added via augment by code that we won't even have compiled yet 18:35
We could have written the whole compiler frontend in Raku instead of NQP if it weren't for the bootstrap problem.
lizmat when I wrote .literalize in dd5125aecdb66263b61 I made it clear that this was intended for use in RakuDoc 18:44
linkable6 (2023-05-16) github.com/rakudo/rakudo/commit/dd5125aecd RakuAST: add .literalize method to selected ::Node classes
lizmat since the setting doesn't have any rakudoc, I thought it was safe to do so
if .literalize is being used for other purposes, we need to fix that
but as long as it's for rakudoc, I don't see a problem with the current approach ? 18:45
nine Actually that message does not limit the use to RakuDOC and instead even points out another potential use: "It seems likely that this functionality might actually also be used
for some constant folding purposes"
lizmat *might*
nine "might be used for something else" is actually the opposite of "only for a specific purpose" 18:46
It's like < and >=
lizmat ok, still I don't see the problem with the current approach: if we start working on the setting, we can fix the cases that try to use .literalize too early ? 18:48
Geth rakudo/main: 0bcab7a86f | timo++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp
Don't try to lower signatures with parametric generic types (#5804)

Fixes "inconsistent bind result" for signatures with a type capture followed by @ or % sigiled params using the typevar, or when such a param uses a type capture param of a role.		 19:18
timo ^- should we create an issue for this so that we can mark it "testneeded"? 19:19
lizmat I'll eb adding tests for that :-) 19:22
*be 19:23
Geth rakudo/main: d773990055 | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: fix bogus parse error when trying to call trait_mod:<is>

When trying to determine whether a name is a meta op, we call back into the parser to just try and see whether we find any match. However when the parser throws a panic, this does not mean that we have to abort. It simply means that it's not a meta op at all.		 19:43
rakudo/main: adae956262 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: don't stumble over parameter terms on blocks
Geth rakudo/main: 42d49a979d | (Elizabeth Mattijsen)++ | src/Raku/ast/literals.rakumod
RakuAST: don't create IntLiterals for Int type objects

Found while working on #2599		 20:43
roast: df7f71b719 | (Elizabeth Mattijsen)++ | S06-currying/misc.t
Fix more .assuming tests

  - adjust tests for signatures that were incorrect, and todo them
  - skip tests that currently don't work without .assuming either
  - fix tests that were too implementation detail specific
Part of work on #2599		 21:01
roast: 63fb7c1079 | (Elizabeth Mattijsen)++ | S06-currying/positional.t
More .assuming test fixes

  - remove tests checking on unnamed args in signature
  - fix tests that check signature for default values, and todo them
  - remove tests that pass Nil as an arg, which will never work
rakudo/bootstrap-rakuast: 8 commits pushed by (Stefan Seifert)++ 21:14
rakudo/main: 4ee9503bdc | (Elizabeth Mattijsen)++ | 2 files
Re-imagine .assuming using RakuAST

This completely removes the old implementation of .assuming by a RakuAST based implementation. For the users, there should be no noticeable difference, apart from:
  - slightly faster creation of new Callable
... (17 more lines)		 21:17
lizmat *phew* in the past weeks I learned more about signatures than I have ever wanted to know about signatures :-) 21:19
nine Well this is stumping me: P6opaque: no such attribute '$!signature' on type Code in a WhateverCode when trying to bind a value 21:38
Actually even before: Nominal type check failed for parameter '<anon>'; expected Rakudo::Iterator::Empty but got Rakudo::Iterator::Empty 21:40
lizmat perhaps a container slipped in somewhere, that the error message doesn't show ?
nine No, Code is missing from the mro 21:55
timo well for the R::I::E case it could be the mismatch of deconts / non-deconts 22:06
timo could also be two same but not identity-equal type objects / STables? 22:06
nine Oh boy....apply-traits has a CATCH handler to collect any exceptions from applying traits and report them as sorries. We just don't get far enough to do so. And there's yet another AT-POS call in apply that of course fails 22:08
I ought to systematically replace those

Powered by Cro and the Raku® Programming Language.

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

Thank you!