🦋 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: MasterDuke17++ created pull request #5352:
Use new stat syscalls		 02:56
Geth rakudo/main: 244ea5e9d6 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add &*DD as an alias of dd()

For *much* easier debugging of grammar and actions		 08:50
rakudo/main: 632f952b0a | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: Streamline lang-setup a bit

And also introduce the RAKU_LANGUAGE_VERSION environment variable to set the language version to be used if no "use v6xxx" has been seen.
Sadly this exposed a bug in language version setting: $*RAKU is set correctly with e.g. a "use v6.*", but the actual grammar being used, is still the default, aka the 6.d grammar.		 09:03
Geth rakudo/main: 88ca1e382c | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Streamline check-variable

Still not fully grokking what is going on with metaops though		 10:21
rakudo/main: e5d5d48eb1 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Streamline obs handling

And get rid of worryobs, as it is not being called anywhere
rakudo/main: a17588f81b | (Elizabeth Mattijsen)++ | 2 files
RakuAST: kebab-case typed_panic
 10:37
rakudo/main: b20c79932f | (Elizabeth Mattijsen)++ | 2 files
RakuAST: kekab-case typed_sorry
 10:46
rakudo/main: 8a7f4b722d | (Elizabeth Mattijsen)++ | 2 files
RakuAST: kebab-case typed_sorry
 10:57
lizmat meh, that was typed_worry 11:11
TIL that: subst($orig, /foo/, "bar") is a thing in NQP 11:35
Geth rakudo/main: 1d5a9508e7 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Streamline build-exception and associated

Still not grokking them completely :-(		 13:05
lizmat hmmm... feels like $*RESTRICTED is a leftover from the obsolete restricted setting? 13:15
ah, I guess not: it's being set in src/core.c/INTERPOLATE 13:16
intriguing though there don't appear any tests for it ? 13:17
Geth rakudo/main: 779f0f7992 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove "security" method

It was only being called once, so move the logic there		 13:28
vrurg lizmat: have you resolved the problem with `nano`? 13:46
lizmat nope
vrurg Sorry, I was afk all day yesterday. 13:47
lizmat no worries
so, use v6.e.PREVIEW and v6.* set $*RAKU and such
but the grammar that's being used, is still 6.d
vrurg The legacy grammar supports it by introducing explicit token term:sym<nano>, actually. That is how it works, I think.
`use v6e.*; say CORE-SETTING-REV;` shows no difference between the legacy and RakuAST. 13:51
lizmat nano was just the canary... 13:52
it isn't limited to nano
I don't think? 13:53
vrurg There are more 'term' definitions in the legacy grammar, if memory doesn't betray me.
CORE-SETTING-REV is declared in the settings. If it is 'e' then there is no way CORE.e is not loaded. 13:54
Therefore the problem is not in a term not available – it's not seen. 13:55
lizmat m: use v6.e.PREVIEW; say $*RAKU; say //42; 14:00
camelia Raku (6.e)
True
lizmat m: Q|use v6.e.PREVIEW; say $*RAKU; say //42|.AST
camelia ===SORRY!=== Error while compiling
Null regex not allowed. Please use .comb if you wanted to produce a
sequence of characters from a string.
------> use v6.e.PREVIEW; say $*RAKU; say //⏏542
lizmat not just nano
m: use v6.*; snitch (1,2,3) 14:01
camelia (1 2 3)
lizmat m: Q|use v6.*; snitch (1,2,3)|.AST 14:02
camelia ( no output )
vrurg I'd rather suspect the lookup mechanism.
The CORE is definitely there, but lookups do not see symbols from it.
lizmat ok, I'll look in that direction then... still feels weird 14:03
vrurg m: q<use v6.*; say &prefix:<//>.raku>.AST 14:04
camelia ( no output )
vrurg m: q<use v6.*; say &prefix:<//>.raku>.AST.EVAL
camelia No such method 'raku' for invocant of type 'VMNull'. Found 'raku' on
type 'Mu'
in block <unit> at <tmp> line 1
vrurg m: EVAL q<use v6.*; say &prefix:<//>.raku>.AST
camelia ===SORRY!=== Error while compiling <tmp>
EVAL is a very dangerous function!!! (use the MONKEY-SEE-NO-EVAL pragma
to override this error but only if you're VERY sure your data contains
no injection attacks).
at <tmp>:1
------> L q<use…
vrurg Anyway, plain lookup for the prefix OP works. The symbol _is_ visible. Then it's something about the resolver and/or how the grammar is using it. 14:05
lizmat ack 14:06
vrurg Which I could look into it personally. :( 14:07
vrurg sadly crawls away to start integrating work app with google cloud...
lizmat I wonder if $*R needs updating in lang-setup 14:08
I'll try to see if that makes a difference
Geth rakudo/main: 386cac8a12 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: streamline .NYI and .malformed
 14:19
lizmat nope, that isn't it :-( 14:33
vrurg jdv: guess, you plan a release soon? 15:30
lizmat last thing jdv said was Monday 15:31
vrurg Ok. Just don't want to merge the PseudoStash thing before that. 15:37
Geth rakudo/main: 083f28579f | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Streamline .missing handling

And some more tweaks and fixes		 15:46
rakudo/main: 32e078ca75 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Started on streamlining expressions
 17:05
japhb Is it just me, or is Rakudo starting up much slower than usual these days? 21:01
$ time raku -e ''
real0m0.476s
user0m0.117s
sys0m0.024s
(That's from a fresh Rakudo build.)
japhb In contrast, from back in February: 21:05
$ time rakudo-moar-2023.02-0-g6c2f9194f/rakudo-m -e ''
real0m0.093s
user0m0.091s
sys0m0.017s
OK, confirmed faster start at rakudo-moar-2023.02-232-gef05ef1e2 and slower start at rakudo-moar-2023.05-7-g5be4c809f. I don't locally have any builds between those, looks like I'll have to build some more to bisect this. 21:07
ugexe the startup times for me on 2023.02 and blead are identical for me 21:08
same with 2023.06 21:09
macos m2
japhb That's interesting. Do you happen to have an x64 machine about? I'm wondering if the jit got disabled, or some such arch-specific issue 21:10
Meanwhile I'm building a 2023.04 to start the bisection fun 21:11
ugexe i have a resource limited vm that is x64, it'll take a bit to build those two rakudos though 21:14
japhb Yeah, understood. Thank you for taking a look! 21:18
vrurg japhb: I compared 2023.02 and 2023.05 on Xeon E5-2690 v4 @ 2.60GHz. Makes no difference, 160-180ms for `raku -e ''` 21:20
japhb vrurg: What about 2023.06? 21:31
The earliest in the 2023.05 series I had was -7- so something could have landed between the release and that point
vrurg Didn't have it readily available, but was building. Gimme a sec to try.
japhb Yeah of course. Thanks for helping to investigate! 21:32
vrurg The same, no difference.
japhb WTH is going on?
ugexe yeah, i see no difference on x64 too
japhb wonders if it was a compiler, linker, or C library change between the earlier builds I have on my system and the later ones. 21:33
vrurg japhb: try freshly rebuild .02 and .06 using the same tools, perhaps?
japhb Yeah, going to try that next, once .04 finishes. 21:34
rakudo-moar-2023.04-0-g15df5d8a8 (built fresh) started at full speed. 21:43
rakudo-moar-2023.05-0-g297a1ec35 (built fresh) started SLOW. 22:18
vrurg in unpacking fresh popcorn... 22:22
japhb Heh 22:25
Tried moving .raku and .zef out of the way just in case that was related. Seems no. 22:27
Welp, continue bisecting I guess; trying 2023.04-103-gfac61c28e (first NQP bump after 2023.04) 22:32
Not that I'm actually assuming it's NQP, but it seemed like a reasonable way to rule that out at least. 22:33
rakudo-moar-2023.04-103-gfac61c28e (built fresh) started at full speed. 23:02
2023.04-117-g401b77a8a (next NQP bump commit) next 23:04
rakudo-moar-2023.04-117-g401b77a8a (built fresh) started SLOW. 23:37
Guess I'll try -116- next, because if that is fast, then the NQP bump actually *is* the problem for me. 23:38

Powered by Cro and the Raku® Programming Language.

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

Thank you!