00:54 Altai-man_ joined 00:57 sena_kun left 02:55 sena_kun joined 02:57 Altai-man_ left 04:54 Altai-man_ joined 04:56 sena_kun left
nine jnthn: I wonder if it makes sense to repossess stashes at all instead of cloning them. After all we merge them when we load modules anyway. 06:37
06:55 sena_kun joined 06:57 Altai-man_ left 07:31 jmerelo joined 07:32 ShimmerFairy left, ShimmerFairy joined 07:40 squashable6 left 07:43 squashable6 joined 07:50 Geth left 07:58 Geth joined
jmerelo releasable6: status 08:09
releasable6 jmerelo, Next release in ≈3 days and ≈10 hours. 1 blocker. 143 out of 290 commits logged (⚠ 4 warnings)
jmerelo, Details: gist.github.com/a76aad48561eab2396...992911c63b
MasterDuke how/why would the number of call to TWEAK for a class be two orders of magnitude greater than the number of calls to new? 08:47
08:54 Altai-man_ joined
moritz maybe something calls .bless or so directly without going through .new? 08:57
or it could be a bug
08:57 sena_kun left
MasterDuke hm, this is with Proc::Async. the only relevant .bless i see is in its new 09:01
fwiw, this is the test code i profiled: `my $proc = Proc::Async.new: "perl", "-E", q|for(1..100_000) { say "y" x 100 }|; react { whenever $proc.stdout.lines { say "stdout: $_"; }; whenever $proc.stderr.lines { say "stderr: $_"; }; whenever $proc.start { say "Exit code: {.exitcode}"; done; } }` 09:02
moritz do you know that it's Proc::Async.TWEAK that's called, or it could it be e.g. Promise.TWEAK or so? 09:10
MasterDuke according to the profile, both Proc::Async's TWEAK and BUILDALL have 100k+ calls (not exactly the same number for the two though) 09:12
the file and line numbers match up. i.e., the routine name is 'TWEAK', file is 'src/core.c/Proc/Async.pm6', and line number is 131 09:14
github.com/rakudo/rakudo/blob/mast...c.pm6#L131 09:15
680 calls to github.com/rakudo/rakudo/blob/mast...c.pm6#L122 and 41 calls to github.com/rakudo/rakudo/blob/mast...c.pm6#L123 09:16
09:24 squashable6 left 09:26 squashable6 joined
jnthn nine: Maybe, but what of the STable that points to the stash? 09:32
09:35 leont joined
lizmat Files=1306, Tests=111382, 217 wallclock secs (28.90 usr 8.34 sys + 3033.47 cusr 290.40 csys = 3361.11 CPU) 09:35
MasterDuke i just got some test fails while trying to install File::Which. i think maybe it's trying to find 'per6', but i used the 'raku' executable 10:18
10:30 MasterDuke left 10:38 MasterDuke joined
Geth rakudo: 1402c1d1ed | (Elizabeth Mattijsen)++ | src/core.c/Grammar.pm6
Make sure Grammar.parse can handle Cool again

f10e5bcef1f69f982259faaf started using nqp::chars, which breaks if the thing to parse is a non-Str Cool (such as an Int). Fixed by calling .chars instead. Fixes Grammar::HTTP and Template::Mustache.
10:55 sena_kun joined 10:56 Altai-man_ left
releasable6 Next release in ≈3 days and ≈7 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
11:00 squashable6 left 11:04 squashable6 joined
lizmat afk for a few hours& 11:12
11:47 patrickb joined
[Tux] Rakudo version 2020.05.1-291-g1402c1d1e - MoarVM version 2020.05-97-gb5bb4f8d1
csv-ip5xs0.826 - 0.827
csv-ip5xs-208.074 - 8.679
csv-parser24.885 - 27.371
csv-test-xs-200.390 - 0.400
test7.886 - 7.976
test-t1.945 - 1.963
test-t --race0.989 - 0.991
test-t-2031.575 - 32.117
test-t-20 --race8.970 - 9.808
12:54 Altai-man_ joined 12:57 sena_kun left 13:27 jmerelo left 14:20 patrickb left 14:55 sena_kun joined 14:57 Altai-man_ left 15:50 sjn left 15:51 sjn joined 15:58 leont_ joined 16:08 squashable6 left 16:10 squashable6 joined
Geth rakudo/rakuast: d461b36da5 | (Jonathan Worthington)++ | src/Raku/Grammar.nqp
Add a few more operators to RakuAST-based grammar

Of note assignment, which we don't really compile in an interesting way yet, but this gets us the cases that are handled.
rakudo/rakuast: 607e150f12 | (Jonathan Worthington)++ | src/Raku/ast/variable-declaration.rakumod
Simplify RakuAST variable declaration compilation

We can just use the core symbols that are reachable by virtue of being part of the bootstrap, rather than causing a load of resolutions.
rakudo/rakuast: 4468b1580e | (Jonathan Worthington)++ | 2 files
RakuAST compilation of array/hash init
rakudo/rakuast: da32d0a479 | (Jonathan Worthington)++ | 2 files
Compile basic method calls to RakuAST
16:30 MasterDuke left 16:35 lichtkind joined
timotimo when do wi have a Rakuish based on RakuAST? :) 16:45
rakuuns love their rubbish 16:46
sena_kun What would it do? Post a daily Raphtalia joke? :) 16:48
greppable6, passwordXXXX 16:49
greppable6 sena_kun, Found nothing!
jnthn I think if you run with RAKUDO_RAKUAST=1 in that branch it's already quite ish-y :)
The amount of things sanity tests depend on that I didn't expect to need to do so soon is quite noticeable. Meta-ops and interpolation for two :) 16:50
16:54 Altai-man_ joined 16:57 sena_kun left
moritz does that make roast the insanity tests? :D 17:02
jnthn :D 17:03
moritz at times like this, I wonder how often you've done the whole dance of changing something pretty fundamental, and then working your way up to making the setting compile again and finally the tests pass 17:06
NQP-rx, NQM, nom, GLR specifically come to mind
jnthn Mostly once per new backend I implemented.
moritz + GLR + RakuAST 17:07
.oO( and now the GDO )
jnthn I think pmichaud did NQP-rx
moritz might have, aye
jnthn RakuAST is a bit different though: I'm keeping the two compiler impls side by side for now, so I can compile CORE.setting with the existing one.
That means by the time I really have to deal with CORE.setting, I'll already have dealt with the spectests 17:08
Or a large part of them
So I'm hopeful there'll be rather little that I have to find by debugging core setting compilation. 17:09
I suspect it'll mostly hurt because of all the nqp::op usage
Which doesn't happen in CORE.setting
oops, in spectest 17:10
Though the one that really scares me is NativeCall
Which is $*W.blah all over the shpo
And there won't *be* a $*W any more
The dispatcher stuff scares me far less, in that I suspect I can pull it off with minimal ecosystem impact.
Well, actually, that's not quite true; some nqp::ops will go away for example 17:11
But hopefully ones rarely used
RakuAST will break everything that's dabbled in compiler internals, because the internals won't look the same any more.
lizmat jnthn: what would be the alternative to $*W ? 17:15
perhaps we can already put some shim in place that would make it easier for you ? 17:17
jnthn lizmat: There's no single alternative, since much of the architecture change is to take the logic spread over actions/world and put it into the AST nodes. 17:23
lizmat: Really we'd need to audit usage of it in the ecosystem and see what can be done
greppable6: $*W
greppable6 jnthn, Sorry, can't do that
jnthn greppable6: \$\*W 17:24
greppable6 jnthn, 56 lines, 15 modules: gist.github.com/f40607c1a4861c6d15...baf78a0a14
jnthn If that's really true, I'm less worried: 15 modules is nothing
I feared it would be many more 17:25
lizmat most of those are by the usual suspects
jnthn greppable6: QAST
greppable6 jnthn, 54 lines, 11 modules: gist.github.com/90ffc31cff8051a66d...8f49d9c4ec
jnthn Those'll be in bother too
But yeah, also small number and low author count
Anyways, home time for me 17:26
lizmat oki
jnthn Glad that situation is a bit less bad than I feared
One of those modules I hope to obselete anyway :)
bbl o/ 17:27
lizmat I'm pretty sure Jeff would have liked that
17:33 Kaiepi left 17:36 Kaiepi joined
lizmat wanting to start your positional captures at 1 rather than 0? You can! 18:02
m: "abc" ~~ /$<1>=(.)+(.)/; say $1; say $2
camelia [「a」 「b」]
18:05 MasterDuke joined
Geth rakudo: cd61724806 | (Elizabeth Mattijsen)++ | src/core.c/Hash.pm6
Make Hash.sort a tiny bit faster

A WhateverCode turns out to be faster than a carefully crafted code block with a nqp::getattr. About 17x as fast. Of course, this will be drowned out by the actual sorting, so don't expect much improvement in the end. Saves 1 Scalar allocation per key in the hash.
MasterDuke simpler and faster, nice 18:19
18:55 sena_kun joined 18:57 Altai-man_ left
[Coke] nice 19:43
20:08 raku-bridge3 joined, raku-bridge3 left, raku-bridge3 joined 20:09 lizmat_ joined 20:10 samebchase-1 joined 20:11 Kaeipi joined 20:14 literal_ joined, tbrowder__ joined 20:18 Kaiepi left, tbrowder left, lizmat left, raku-bridge left, literal left, samebchase- left, tbrowder__ is now known as tbrowder 20:19 raku-bridge3 is now known as raku-bridge 20:36 zostay left 20:38 kawaii left 20:54 Altai-man_ joined 20:56 sena_kun left 21:39 zostay joined 21:40 kawaii joined 22:32 lizmat_ is now known as lizmat 22:55 lichtkind left, sena_kun joined 22:56 Altai-man_ left 23:09 MasterDuke left 23:51 leont_ left, leont left