🦋 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.
05:05 guifa left 05:52 finanalyst joined
Geth rakudo/main: c736ec009f | (Jimmy Zhuo)++ | src/Raku/ast/statements.rakumod
RakuAST: Fix while "D" { last }
 06:02
rakudo/main: 403252cf63 | niner++ (committed using GitHub Web editor) | src/Raku/ast/statements.rakumod
Merge pull request #5840 from zhuomingliang/main

RakuAST: Fix while "D" { last }
rakudo/main: 9ebb5c87e1 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: prohibit using attribute accessors as parameter targets in submethods
 06:54
rakudo/main: 038a6e8567 | (Stefan Seifert)++ | 2 files
RakuAST: prohibit attribute access as parameter target in subs
rakudo/main: d505730c5d | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: avoid misleading error when attribute accessor is used in sig outside package
nine 1340
07:04 timo left 07:07 timo joined
Geth roast: 83b89bd1de | (Stefan Seifert)++ | S14-roles/parameterized-type.t
Fix accidental declaration of our scoped role in another role's signature

The declarations made in a role's signature are meant to go into that role's body. However it's illegal to make our scoped declarations inside roles as that scope is generic. Thus it should be wrong to declare an our scoped role in another role's signature and a more picky compiler might complain.		 07:36
rakudo/main: b0ff120046 | (Stefan Seifert)++ | 4 files
RakuAST: prohibit our scoped declarations in roles
 07:41
nine 1341
08:55 samebchase4 joined, gfldex left, samebchase left, samebchase4 is now known as samebchase 08:56 gfldex joined 09:22 sena_kun joined
Geth rakudo/main: 1a8c681367 | (Stefan Seifert)++ | 3 files
RakuAST: allow for parameterization of type with variables

The variable can resolve to a container and that's what the type will be parameterized with.		 09:34
nine I think this is about as far as I'm gonna take it. 09:48
t/spec/S02-types/generics.t, t/spec/S02-types/is-type.rakudo.moar, t/spec/S02-types/nominalizables.t and most likely t/spec/S12-methods/qualified.t are vrurg's generics stuff. 09:49
t/spec/S14-roles/versioning.t fails due to missing POPULATE which feels bogus as I don't think we should require an implementation to generate a POPULATE method. That it's expecting a POPULATE is more a workaround for there being such a method and the test really should make it optional. 09:50
I assume lizmat++ will take care of the 5 failing files in S26-documentation as she's vastly more qualified than me for the RakuDOC stuff. 09:51
And that's it.
Oh, I forgot, there's also t/spec/S04-statements/label.t. It fails 2 cases where the proper behavior is still up for discussion and where I think that the tests are wrong. 09:53
m: @ = (while True { while True { say "WhileLoop"; last } }) # Obviously this is lazy
camelia ( no output )
nine m: @ = (L1: while True { while True { say "WhileLoop"; last L1 } }) # this however is eager and the test requires this, but why would the precense of a label make the loop eager? 09:54
camelia WhileLoop
nine Like I detailed the first time I encountered this spectest file, the code for while/until loops is riddled with bugs and this spectest just enshrines those bugs 09:55
lizmat nine: i just realized re declarator doc bugs, I've been looking at the wrong place 09:57
suppose this case: 09:58
#= leading doc
my $foo = 42
does the leading doc attach to the 42, or to the container of $foo
?
nine I do not have the slightest idea :) I barely have spent any time with RakuDOC at all 10:00
Not just in the RakuAST effort. Even when writing Raku code I haven't used it 10:01
lizmat well, in the legacy grammar, it attached to the value afaics 10:04
in RakuAST it attaches to the container
which I think would be the correct behaviour
it's just that .WHY currently decontainerizes 10:05
and thus never finds the .WHY on the container
(at least, that's my current theory)
nine Well, yes, documenting the variable would make more sense to me than documenting that value. 10:07
lizmat well, I guess in the case of a "my" variable maybe not so much, unless it is exported (can we do that now?) 10:09
anyways, trying to fix MU.WHY sends the settings compilation into a tailspin... so moving that code now to core_epilogue
as we don't need that in the setting itself anyway 10:10
Geth rakudo/bootstrap-rakuast: 15 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/6...0d8fb9bcbf		 10:12
lizmat hmmm... but if we attach it to the container, we would at least to mix in a $!why attribute into it 10:25
which then leads to the question: why do things like Attribute / Block objects have a $!why attribute, when that could have been mixed in when needed ? 10:26
all in all this is starting to look like a legacy house of cards that is pretty fragile :-( 10:27
nine Sounds exactly like my experience with package installation 10:29
lizmat #| leading 10:30
my $a = sub { };
say $a.WHY;
$a = 42;
say $a.WHY;
shows: leading
Sorry, no documentation is attached to Int.
so in the legacy grammar, it is attached to the sub and not $a 10:31
and the spectests are testing for that
so now I have half a mind to just remove those spectests
Geth rakudo/bootstrap-rakuast: 1b0fd7daac | (Stefan Seifert)++ | src/Raku/ast/type.rakumod
RakuAST: don't type check native values in enums
 10:35
lizmat m: role A { has $.a }; my $a = 42; $a.VAR does A(666); say $a.a; $a = 43 # apparently we can't mixin roles into a container :-( 11:45
camelia 666
Cannot assign to an immutable value
in block <unit> at <tmp> line 1
lizmat at least not with infix:<does> 11:46
m: role A { has $.a }; my $a = 42; $a.VAR.^mixin(A); say $a.a; $a = 43 # also not with ^mixin :-( 11:47
camelia (Any)
Cannot assign to an immutable value
in block <unit> at <tmp> line 1
12:18 finanalyst left
lizmat nine: I'm now leaning towards *not* allowing declarator docs on variables 12:28
which provides a bit of a conundrum, as we *do* want to allow declarator docs on attributes
but variables and attributes in RakuAST share the same RakuAST::Var::Declaration::Simple class 12:29
nine: did you ever consider making a RakuAST::Attribute class, as a subcllass of RakuAST::Var::Declararion::Simple ? 12:38
argh, now I find that subroutines that do not take any args *can* have trailing declarator doc after the opening { 12:56
but subroutines that *do* take arguments can not, as they potentially would apply to the parameter
so I'm thinking of simply disallowing any trailing declarator docs on blocky things 12:58
13:13 rakkable left, rakkable joined
lizmat rakkable: eco-pr ^#= 13:13
rakkable lizmat, Running: eco-provides ^#=, please be patient!
13:13 rakkable left 13:14 rakkable joined 13:22 Altai-man joined 13:24 sena_kun left 13:25 guifa joined
lizmat just finds 4 community modules that use declarator docs incorrectly *sigh* 13:29
nine lizmat: As its name says VarDeclaration::Simple is so complicated that I do not dare touch it unless I absolutely must 13:48
After all a "simple" var declaration can be a lexical, a parameter, an object attribute or a class attribute or a dynamic variable 13:50
Geth rakudo/main: 8bdbc9f8d9 | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: only set declarand for attributes

Setting declarator docs on variables in general is currently impossible without a significant overhaul of the way declarator docs are being handled: currently, object types that support declarator docs have a
  $!why attribute, which is usually not used. An approach with mixing
in a $!why attribute on demand on Scalar containers proved to be a failure.
So all variable declarations (apart from attributes) are now ignored.		 17:01
lizmat 1342
roast: 63732f8490 | (Elizabeth Mattijsen)++ | S26-documentation/why-trailing.t
Put trailing declarator doc at right position

In RakuDoc this is a lot more strict than in the legacy grammar		 17:06
lizmat 1343
Geth roast: 66b5f51a26 | (Elizabeth Mattijsen)++ | S26-documentation/why-both.t
Put trailing declarator doc at right position

In RakuDoc this is a lot more strict than in the legacy grammar		 17:08
lizmat 1344
17:27 finanalyst joined
lizmat nine: looks like t/spec/S26-documentation/block-xxx is blocking on #( ) constructs not working 17:49
which appears to be related to quibble handling
Geth roast: ef16fc6c67 | (Elizabeth Mattijsen)++ | S26-documentation/block-trailing.t
Put trailing declarator doc at right position

In RakuDoc this is a lot more strict than in the legacy grammar		 18:42
[Coke] nine++ 18:53
lizmat++
by my count, that leaves 6 spectests? 18:54
(many of which nine listed above as needing attention)
amazing work. 18:55
Geth roast: caf6dd4137 | (Elizabeth Mattijsen)++ | 2 files
Declarator doc #| and #= *must* have a whitespace following

Maybe we can relax that at a later point, but the RakuDoc definition states there must be whitespace. So enforce that in the tests		 18:57
rakudo/main: 7b0f03ea70 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: must have whitespace after #| and #=

As stated in the RakuDoc v2.0 definition		 18:59
lizmat 136
1346 I mean :-)
[Coke] looks like we lost some make test - 26 failures now. 19:10
lizmat yeah :-)
[Coke] down to 140 passing make test. will see if I can golf some of them.
lizmat you mean without RAKUDO_RAKUAST=1 ? 19:11
[Coke] oh, 6 of the are macros, which I think are a very likely cut.
lizmat: no, with that
we were passing 145/166, now at 140
lizmat hmmm... will look at that tomorrow probably :-) 19:12
[Coke] ok. 19:15
oh - outside of a release, I just did a make spectest which said inline::perl5 isn't installed, so I ran that zef command it suggested, and then ran spectest again ... still get the "not installed" message. so I am wondering if the issue is NOT with the Akefile. 19:19
lizmat it probably isn't... I noticed that just now myself 19:32
afk& 19:42
[Coke] spectest isn't clean here. 20:17
[Coke] updates github.com/rakudo/rakudo/issues/5841 20:20
20:23 codesections joined 20:25 codesections left 21:54 finanalyst left 22:25 guifa left 22:39 guifa joined 22:43 Altai-man left

Powered by Cro and the Raku® Programming Language.

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

Thank you!