🦋 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.
01:11 kjp left 01:13 kjp joined 01:14 kjp left, kjp joined 08:24 MasterDuke left
Geth rakudo/main: a04a819905 | (Stefan Seifert)++ | 4 files
RakuAST: support trait_mod:<will>

Fixes: my $begin; my $b will begin { $begin ~= "b" }; say $begin		 08:47
rakudo/main: 56a80347be | (Stefan Seifert)++ | 2 files
RakuAST: remove obsolete IMPL-CHECK call from IMPL-BEGIN-TIME-EVALUATE

Before the rakuast-phase-cleanup branch, IMPL-CHECK was also responsible for running BEGIN time. It no longer is, so there's no point to enforcing CHECK time before we make BEGIN time calls.
rakudo/main: ce311700dd | (Stefan Seifert)++ | src/Raku/ast/statementprefixes.rakumod
RakuAST: fix CHECK phasers with expressions instead of blocks

CHECK takes a blorst, i.e. a block or statement. BEGIN time evaluation can either run a code object or an expression, but not statements. Thunk all expressions before evaluating to get around this.
Fixes my $f; CHECK $f ~= 1		 08:48
10:41 dawids joined 11:41 dawids left
Geth rakudo/main: 4397c0e245 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: some small deparsing/highlighting fixes
 12:36
lizmat heh, while looking at some threading issues, I think I found one of the reasons why precomp on RakuAST is a mess 12:46
my constant $compilation-id = nqp::box_s(
nqp::sha1($*W.handle.Str ~ nqp::atkey($config,'source-digest')),Str
);
or at least, will need to be fixed to make RakuAST core
Geth rakudo/main: 9f34623f81 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove active mention to $*W
 13:11
13:48 donaldh joined
nine Looks like we're not running out of low hanging fruit at all :) 13:51
lizmat: I already got a commit dealing with $*W in Variable.rakumod 14:04
lizmat cool!
Geth rakudo: patrickbkr++ created pull request #5624:
Add a test for intepolating variables into grammars		 14:33
rakudo/main: cd67429898 | (Stefan Seifert)++ | 5 files
RakuAST: fix adding phasers through will trait

The will trait tries to add phasers either to the current block or to the compunit. It needs to access those even in a RakuAST based compiler.		 14:38
nine With this we're at 1126 14:42
Geth rakudo/main: 06e1fe6cea | (Stefan Seifert)++ | src/Raku/ast/compunit.rakumod
RakuAST: fix CHECK phasers added through will trait accidentally getting added as END phasers
 15:21
rakudo/main: f61870cfee | (Stefan Seifert)++ | 2 files
RakuAST: ensure CHECK phasers are run in reverse order of declaration

Ironically, this means that StatementPrefix::Check is no longer CheckTime, but instead has to be BeginTime to add the phaser to the compunit's queue.
nine And this makes it 1129
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 16:41
nine Surprisingly this brings us up to 1131
17:01 sena_kun joined
Geth rakudo/main: fab0ae21e9 | (Patrick Böker)++ (committed using GitHub Web editor) | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Assorted grammar tests

Pass with RakuAST, fail with the legacy compiler.		 17:21
rakudo/main: 43d2b0fb49 | (Stefan Seifert)++ | src/core.c/Exception.rakumod
Support will complain on X::Syntax::Number::LiteralType
 18:37
rakudo/main: 0be319b8db | (Stefan Seifert)++ | 2 files
RakuAST: ensure will complain blocks get code-gened
nine I guess there's always room for one more: 1132
Geth rakudo/main: 4d35f1e3e9 | (Stefan Seifert)++ | 2 files
RakuAST: support ~ regex metachar

Fixes regex { '(' ~ ')' a* }		 20:36
rakudo/main: 70059eb1a4 | (Stefan Seifert)++ | 3 files
RakuaST: support proto token
nine 1134 20:37
I thought maybe proto token was a simple fix, but that just opened the door to a whole load of regex issues. And the commit I pushed is just the proto side. Still need to actually support the multis attached to it. 20:38
ugexe m: Nil.asldkjfalskjdf 20:43
camelia ( no output )
ugexe why?
lizmat m: say Nil.bhkjhkghk
camelia Nil
lizmat the idea being that anything called on Nil will produce Nil 20:44
ugexe im having trouble thinking of a situation where one would want this behavior 20:45
lizmat from S02-bits: 21:01
"Any undefined method call
on C<Nil> returns C<Nil>, so that C<Nil> propagates down method call chains.
Likewise any subscripting operation on C<Nil> returns C<Nil>."
[Coke] You can't fool me, it's Nils all the way down. 21:06
ugexe ok, but im trying to thikn of a time where i've written code and would have wanted that behavior. maybe i'm overlooking something 21:15
[Coke] fail as late as possible. 22:12
check for Nil in the last step of the calc so you don't have to do it after each step. Yah, I don't write that way either.
22:30 sena_kun 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!