🦋 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.
Geth rakudo/main: 02ce95d902 | (Elizabeth Mattijsen)++ | t/02-rakudo/12-proto-arity-count.t
Allow Mu:U as synonym for Mu in testing signatures
 10:16
nqp/main: cb8bded5a9 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for no-lexicals in frame fix, MasterDuke++
 10:21
Geth rakudo/main: 60309b6aee | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for no-lexicals in frame fix, MasterDuke++
 11:32
lizmat m: say Q|:(2)|.AST.statements.head.expression.signature.parameters.head 13:22
camelia RakuAST::Parameter.new(
type => RakuAST::Type::Simple.new(
RakuAST::Name.from-identifier("Int")
),
value => 2
)
lizmat nine: looking at "value => 2", feels like that should be: "value => RakuAST::IntLiteral.new(2)" or "value => RakuAST::Literal.from-value(2)" ?? 13:23
nine Wouldn't work for negative numbers 15:03
lizmat value => -1 ? 15:04
nine Yeah, that would probably work out ok, though these would be the only negative number literals 15:27
But then, what would this exercise actually solve?
lizmat my point is that it currently seems to codegen incorrectly 16:50
nine ^^
nine how?
Geth roast: 548e7b9aad | (Stefan Seifert)++ | S12-attributes/class.t
Add missing } in test

The test was relying on the implementation detail that the invalid $!a access would be reported before the parse error due to the missing }.		 16:53
lizmat nine: because in "my $a = 1" the one is codegenned as RakuAST::IntLiteral.new(1) 16:55
and in "sub a(2) { }' the 2 is codegenned as "2" instead of RakuAST::IntLiteral.new(2)
nine That's not codegen, that's parsing. And it's just a different and arguably weird way that parameter literals are parsed. Who's to say it's wrong? 16:57
After all:
m: sub a(2) { }; a(2);
camelia ( no output )
nine m: sub a(2) { }; a(3);;
camelia Constraint type check failed in binding to parameter '<anon>'; expected 2 but got 3
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat ok, if "1" is arguably as right as RakuAST::IntLiteral.new("1"), why do we have the RakuAST::IntLiteral class at all then ? 17:01
Geth rakudo/main: 11 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/6...84eb2ff259
nine 1251
Because of:
m: 1
camelia WARNINGS for <tmp>:
Useless use of constant integer 1 in sink context (line 1)
lizmat looks like you're feeling better :-) 17:02
nine You can't just put a literal value in the AST
lizmat then why is it ok in a signature ?
nine But let's flip the question: if RakuAST::Parameter.new(... value => 2) is wrong, why is RakuAST::LiteralInt.new(value => 2) right?
It's ok for a Parameter because the Parameter does know what to do with the value. Same as LiteralInt 17:03
lizmat IntLiteral, but yeah
hmmm... the IntLiteral class has special QASTing logic, perhaps that would be a reason for having it? 17:04
nine To be honest, at this point I don't care whether there's a good reason for this seemingly arbitrary distinction. Maybe we could unify it and get rid of that complicated handling for negative values I had to put in. But what we have works. 17:05
Fever's gone and with it the headache. Haven't felt hungry since Sunday though, despite eating very little. 17:06
lizmat glad to hear you're feeling better.... I started having a cold on Monday last week, thought I was over it, but alas 17:08
m: sub a([2]) { }; dd &a.signature.params.head # looks like Parameter.raku could use some TLC :-) 17:15
camelia Positional = @ (2)
lizmat m: sub a(@ (2)) { dd }; a [2] # surprised to see it's actually valid syntax 17:16
camelia sub a(@ (2))
nine "surprised to see it's actually valid syntax" I get that a lot 17:26
lizmat hehe
oh what a tangled web we weave :-)
Geth roast: a47ca2b065 | (Elizabeth Mattijsen)++ | S06-currying/positional.t
Weed out .assuming tests (part 1)

As part of work on #2599 and its new implementation, it became clear that a lot of these tests are testing a particular implementation's side effects, rather than the inherent functionality.
The new implementation of .assuming produces different signatures ... (26 more lines)		 18:07
rakudo/main: 00a93bf827 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: don't call blocks used as attribute defaults prematurely

Need to put blocks in non-sink context to ensure they are not called immediately but instead used as default value.
Fixes: class Foo { has $.code = { die } }.new		 19:55
rakudo/main: f8b15dcc6a | (Stefan Seifert)++ | 2 files
RakuAST: make attributes available before class is composed

Attaching to the class right away means that we have to re-sequence the attribute's BEGIN handler a bit, so early traits are applied before we generate the attribute's meta object.
Fixes: BEGIN $?CLASS.attributes
Geth rakudo: 0rir++ created pull request #5800:
Test and fix that Instant.from-posix-nanos and Instant.from-posix match.		 21:04

Powered by Cro and the Raku® Programming Language.

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

Thank you!