🦋 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.
MasterDuke jdv++ 01:33
lizmat m: say Q|foo(42)|.AST 17:13
camelia ===SORRY!=== Error while compiling
Undeclared routine:
foo used at line -1. Did you mean ''?
lizmat nine: ^^ I'd say that is wrong, it should complain at EVAL time if there is truly no sub found 17:14
patrickb I have just uploaded the binary release archives for 2023.06 to rakudo.org. Yay! 18:18
lizmat patrickb++ 18:20
nine m: foo(42) 19:16
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
foo used at line 1
nine lizmat: that's just the same. Subroutine calls are resolved at compile time and we complain if we can't do that.
lizmat I guess we then need some post CHECK time or something like that 19:17
because I could be building an AST with the .AST function, which references foo 19:18
and then later combine that AST with another AST that *does* contain the "foo" sub
that currently doesn't work :-( and makes Formatter more convoluted atm 19:20
so it feels to me we need a AST CHECK time functionality, and an EVAL CHECK time functionality
I mean, we should see RakuAST as building blocks, no? 19:22
nine Sure, RakuAST nodes are building blocks. .AST is a debugging aid 19:25
lizmat well, I'm at a bit of a conundrum re q:o/%s/ being compile time then 19:29
in the current code, this references some helper subs that are in scope
however, they do not get properly QASTed, or maybe bytecoded, probably because these subs are not in the sc 19:30
so I'm not adding the ASTs of these subs to the generated AST, and those ASTs are generated from the code of the original subs using .AST 19:32
this for maintenance / development convenience
nine So....there is some bug and you are trying to work around that but that is tedious so you use a debugging aid that was never meant for such a thing and it doesn't work out well? 19:42
lizmat from a conversation with jnthn I gathered that it would be hard to fix, these missing subs 19:45
nine When has that ever kept us from fixing things? :D 19:46
Well, except for the still existing race condition in MoarVM's expression JIT compiler...
lizmat ok, let's see if I can golf it
nine; golfed gist.github.com/lizmat/91930d595ca...9953a8f26a 19:58
afk for a bit& 20:05
timo nine: why is there a race condition in the exprjit compiler, we never run more than one thread that does speshing and jitting 22:40
ugexe github.com/rakudo/rakudo/blob/ec62...y.pm6#L178 Shouldn't this read be protected? 23:45
yep, it was broken in github.com/rakudo/rakudo/commit/95...03b53597ba 23:48
the Lock::Soft code was eventually reverted but the original protected block wasn't returned

Powered by Cro and the Raku® Programming Language.

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

Thank you!