🦋 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.
00:00 reportable6 left 00:01 reportable6 joined 01:51 linkable6 left, coverable6 left, unicodable6 left, releasable6 left, shareable6 left, evalable6 left, sourceable6 left, notable6 left 01:52 unicodable6 joined 01:53 notable6 joined, shareable6 joined, releasable6 joined, coverable6 joined, sourceable6 joined 01:54 linkable6 joined, evalable6 joined 02:40 MasterDuke joined
Geth rakudo: MasterDuke17++ created pull request #5352:
Use new stat syscalls
03:21 squashable6 left, squashable6 joined 04:48 squashable6 left, coverable6 left, benchable6 left, shareable6 left, nativecallable6 left, reportable6 left, releasable6 left, notable6 left, committable6 left, evalable6 left, sourceable6 left, quotable6 left, greppable6 left, unicodable6 left, linkable6 left, statisfiable6 left, tellable6 left, bloatable6 left, bisectable6 left, tellable6 joined 04:49 statisfiable6 joined 04:50 unicodable6 joined, committable6 joined, nativecallable6 joined, bisectable6 joined, benchable6 joined, greppable6 joined, shareable6 joined, linkable6 joined 04:51 notable6 joined, releasable6 joined, quotable6 joined, bloatable6 joined, squashable6 joined, evalable6 joined, reportable6 joined, sourceable6 joined, coverable6 joined 05:51 unicodable6 left, bloatable6 left, greppable6 left, notable6 left, releasable6 left, nativecallable6 left, statisfiable6 left, squashable6 left, reportable6 left, bisectable6 left, shareable6 left, evalable6 left, sourceable6 left, tellable6 left, committable6 left, benchable6 left, linkable6 left, quotable6 left, coverable6 left, squashable6 joined 05:52 shareable6 joined, releasable6 joined, notable6 joined 05:53 linkable6 joined, greppable6 joined, quotable6 joined, bloatable6 joined, sourceable6 joined, benchable6 joined, committable6 joined 05:54 statisfiable6 joined, reportable6 joined, evalable6 joined, tellable6 joined, nativecallable6 joined, unicodable6 joined, bisectable6 joined, coverable6 joined 06:00 reportable6 left 06:01 reportable6 joined 07:01 shareable6 left, bisectable6 left, squashable6 left, evalable6 left, statisfiable6 left, coverable6 left, benchable6 left, unicodable6 left, quotable6 left, nativecallable6 left, linkable6 left, notable6 left, sourceable6 left, committable6 left, bloatable6 left, greppable6 left, releasable6 left, tellable6 left, reportable6 left, reportable6 joined, tellable6 joined, evalable6 joined, sourceable6 joined, shareable6 joined, unicodable6 joined 07:02 committable6 joined, statisfiable6 joined, releasable6 joined, notable6 joined 07:03 bloatable6 joined, nativecallable6 joined, coverable6 joined, linkable6 joined, bisectable6 joined, squashable6 joined, benchable6 joined, greppable6 joined, quotable6 joined 08:22 sena_kun joined
Geth rakudo/main: 244ea5e9d6 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add &*DD as an alias of dd()

For *much* easier debugging of grammar and actions
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:29 evalable6 left, linkable6 left 09:30 evalable6 joined 09:31 linkable6 joined 09:46 NemokoschKiwi joined
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
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
rakudo/main: b20c79932f | (Elizabeth Mattijsen)++ | 2 files
RakuAST: kekab-case typed_sorry
rakudo/main: 8a7f4b722d | (Elizabeth Mattijsen)++ | 2 files
RakuAST: kebab-case typed_sorry
lizmat meh, that was typed_worry 11:11
TIL that: subst($orig, /foo/, "bar") is a thing in NQP 11:35
12:00 reportable6 left 12:03 reportable6 joined 12:51 MasterDuke left
Geth rakudo/main: 1d5a9508e7 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Streamline build-exception and associated

Still not grokking them completely :-(
13:13 finanalyst joined
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:29 sena_kun left 13:31 sena_kun joined
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)
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
lizmat nope, that isn't it :-( 14:33
15:19 NemokoschKiwi left
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
15:44 finanalyst left
Geth rakudo/main: 083f28579f | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Streamline .missing handling

And some more tweaks and fixes
rakudo/main: 32e078ca75 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: Started on streamlining expressions
18:00 reportable6 left 18:01 reportable6 joined 18:08 finanalyst joined 18:12 finanalyst left 20:26 MasterDuke joined
japhb Is it just me, or is Rakudo starting up much slower than usual these days? 21:01
$ time raku -e ''
(That's from a fresh Rakudo build.)
21:02 sena_kun left
japhb In contrast, from back in February: 21:05
$ time rakudo-moar-2023.02-0-g6c2f9194f/rakudo-m -e ''
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