01:15 FROGGS joined 02:17 FROGGS joined 06:29 lizmat joined 06:31 woolfy joined
nwc10 does t/spec/S06-advanced/wrap.rakudo.moar fail tests for everyone, or just for me? 07:05
07:08 zakharyas joined 07:44 FROGGS joined
FROGGS nwc10: for everyone 08:04
see github.com/coke/perl6-roast-data/b....out#L2389 08:05
(see these fails too)
nwc10 jnthn: some MOAR things now SEGV or make ASAN unhappy 08:32
in theory I have a meeting right now, but one of the business folks is not yet in
(all the tech folks are. This is strange)
missing person located. 08:38
had sneaked into the building without anything spotting him
jnthn nwc10: S17 things? 08:40
08:47 brrt joined
brrt \o #moarvm 08:51
jnthn o/ brrt 08:52
brrt o/ jnthn
how was the weekend?
jnthn A bit rainy, but fine otherwise. 08:53
Yours?
brrt tiring, long train rides, otherwise also fine :-) 08:54
brrt is looking at some notes he made 08:56
compeletely senseless rant: why do people insist that 'static types' are 'designed for correctness' 08:57
static types are for efficient codegen and have been that since fortran 08:58
such people have never had to use c, i think
jnthn Trouble is, there's lots of examples of static types out there, and they don't all carry equal value/usefulness. 09:00
C in particular doesn't promise much.
Java's type system is mostly geared towards being able to pop up a method list when the programmer types a "." in Eclipse, or something. :) 09:01
brrt that is... somewhat harsh, but i think it's true :-)
also - and importantly - it's not like type errors are really a big class of bug
jnthn Well, what I said is just another way of saying "proving the absence of calls to non-existing methods" :) 09:02
brrt iirc, ruby folks are madly in love with calls to non-existing methods
jnthn Well, if you've got a method to make them start existing... :) 09:04
uh, no pun intended :)
hah, I got something to SEGV
brrt is not seeing the pun 09:06
a segv in compiled-code-with-debugging-instructions is /never/ as bad as a segv in generated code without such instructions
jnthn True 09:07
brrt although gdb helps with those, too 09:08
jnthn My debugger shows I have 17 threads running at the point I SEGV, though :)
brrt oh... that can be nasty
in a wholly different way
hmm, what do you think of splitting the jit files in moar files, i.e. taking a bit of time to clean up? 09:11
jnthn If you feel it's going to be easier to move forward after some cleanups, go for it 09:12
brrt ok, will do :-) 09:13
hmm, how do you feel about me claiming the prefix MJ rather than MVMJit ? 09:21
jnthn I've tried to keep everything starting with MVM so far so we arne't too evil to embedders. 09:24
brrt fine :-)
that is a good reason
brrt is off to get some tea 09:31
bbiab
dalek arVM: 1f3a2f5 | jnthn++ | src/core/fixedsizealloc.c:
Fix logical bug in fixed-size-allocator.

Affected the multi-threaded code path.		 09:55
arVM: f3e999d | jnthn++ | src/core/frame.c:
Fix capturelex race condition.
nwc10 jnthn: t/spec/S06-advanced/wrap.rakudo.moar t/spec/S17-lowlevel/lock.rakudo.moar t/spec/S32-list/roll.t t/spec/S32-list/pick.rakudo.moar t/spec/integration/99problems-51-to-60.t t/spec/integration/advent2010-day11.t; 10:39
Oh, goalposts moved. Retest time 10:40
at least one was a backtrace including the fixed size allocator
jnthn Yes, I'm hoping that may nail it. 10:41
10:56 carlin joined
nwc10 jnthn: now, total fails are t/spec/S06-advanced/wrap.rakudo.moar t/spec/S17-lowlevel/lock.rakudo.moar t/spec/S32-list/roll.t t/spec/S32-list/pick.rakudo.moar t/spec/integration/99problems-51-to-60.t 11:09
t/spec/S06-advanced/wrap.rakudo.moar is a Rakudo issue
t/spec/S17-lowlevel/lock.rakudo.moar is our old friend
the last three are triggering ASAN doing its pavement pizza thing 11:10
and go away with spesh disabled
jnthn Oh...
Can I get a backtrace on the last 3?
nwc10 yes
jnthn On lock.rakudo.moar, I currently have two patches in the works
nwc10 last is paste.scsys.co.uk/404224 11:12
paste.scsys.co.uk/404226 11:14
11:14 brrt joined
nwc10 paste.scsys.co.uk/404227 11:15
looks like the last two I pasted are the same underlying bug
FROGGS pavement pizza? 11:19
I wonder if I should google that term
nwc10 euphamism for puke
FROGGS ahh 11:20
:o)
dalek arVM: 772a216 | jnthn++ | src/6model/reprs/ConditionVariable.c:
Missing MVMROOT in ConditionVariable setup.
 11:48
arVM: 8730ef5 | jnthn++ | src/ (5 files):
Don't share cached Lexotics over threads.

Doing so leads to a race on the result slot, which can cause all kinds of trouble.
brrt what, actually, is a lexotic? 11:53
jnthn A place to throw to, located lexically
Used for return
brrt oh.... 11:55
ok :-)
dalek arVM: e2d941b | jnthn++ | src/spesh/osr.c:
Clear logging bits after OSR finalize.
 12:00
jnthn nwc10: That one may (or may not...) help with the pick/roll ones 12:01
nwc10 will tyest 12:02
jnthn gist.github.com/anonymous/8f407afdb8cccc1ed09c that TimToady reported exploding runs nicely for me by now, though I've a debug build with GC every 16KB or so. 12:11
If anybody on non-Windows cares to test it against MoarVM head, please do. (Note, you'll need to rebuild your Rakudo for this bump, or at least the extops) 12:12
FROGGS rebuilds 12:14
jnthn: that script runs fine here 12:17
jnthn Cool 12:20
12:22 jnap joined
jnthn *sigh* the start.t and batch.t failures I typically see under load are 'cus the tests use sleep 12:24
nwc10 sin! 12:25
most lazy way I found to acchieve synchronisation in tests was to open a pipe, and use EOF as the "mutex" 12:26
ie, create pipe, after (possibly implied) fork close writer and reader as usual
so that pipe has one reader and one writer 12:27
and then the reader simply blocks on a read
and the writer end closes the pipe when it's done whater it needed to do
ensuring ordering between writer and reader
it's portable, if your pipe implementation is portable enough :-) 12:28
jnthn Well, this is testing stuff in-process, given there's threads... 12:36
dalek arVM: 3a74ab0 | jnthn++ | src/6model/reprs/ConcBlockingQueue.c:
Some NULLing in gc_free, for easier bug hunting.
 13:06
arVM: f0b3898 | jnthn++ | src/io/eventloop.c:
Re-ordering to avoid race on event loop startup.
brrt doesn't seem to be very productive today :-( 13:12
jnthn brrt: Aww. How's the cleanup going? 13:21
brrt bits and pieces 13:26
basically, i want to move all graph manipulations to a graph.c, and i want to move logging / bytecode dumping also to a file of its own, and the compiler driver, too 13:27
and i /may/ want to split the dynasm files into pieces, but i suspect that will be ugly wrt building 13:28
13:28 woolfy left
brrt matter of fact, i want to do a bit too much in too few steps 13:29
because i /also/ want to merge return values handling with c calls
jnthn Do a piece at a time; that way, if something breaks, you'll know what's to blame.
brrt :-) ok, will do 13:30
dalek arVM: 9c67fc8 | jnthn++ | src/io/asyncsocket.c:
A bunch of missing MVMROOTing in asyncsocket.
brrt i also want to split primitives into arithmetic, comparison, access
jnthn Seems I really wasn't on the ballmer peak when I wrote that code...
13:39 lizmat joined
dalek arVM: 9f2180b | jnthn++ | src/core/interp.c:
exit should just get out quick.
 13:39
13:41 cognominal joined 13:44 sergot joined 13:48 tadzik joined 13:49 btyler joined 13:50 masak joined
jnthn thinks he's an idea what's making the async http thing fall in a heap - or at least one reason for it - on Moar... 13:52
Could do with a walk; bbiab 13:53
timotimo so ... we have a number that stores how many generations an object has survived, right? 14:41
jnthn back
timotimo: no 14:42
timotimo ah
that's good, then :)
jnthn Well
We do, but it's 0, 1, or many :)
timotimo because i was thinking there's a bunch of spots in the young generation where you can say that all objects "to the left" have "survived N collections already"
and that would give us extremely cheap ways to talk about any number of survived generations without per-object overhead
jnthn So only invovles about 2 bits 14:43
timotimo i suppose we already have the bits to spare and don't need more than 0, 1, 2 or many
jnthn Mostly you just need some way to avoid premature promotion 14:44
timotimo mhm
we don't really have a way to check how many generations after being promoted an "old" object gets freed, right?
because gen2 has a free-list that causes fragmentation
jnthn Right, no way to answer that at present. 14:45
Well, it's collections rather than generations
timotimo er, yes
jnthn We only collect gen2 once ever 25 nursery collections, fwiw. 14:46
*every
timotimo ooc, how did you tune that number so far?
FROGGS that was my guess also.... we could tune it again at some point 14:48
jnthn Largely using the NQP and Rakudo build
It makes a rather large difference.
timotimo this needs a quick recompile on every change, aye? 14:49
jnthn yeah
timotimo well, recompiling moar only takes half a minute or probably less ... and this is only very partial, isn't it?
or does that number live in a header?
jnthn It's in a header
timotimo ah, so it'll recompile everything :)
jnthn Note also, though, that in the long run we may well want a more dynamic strategy
FROGGS so that these numbers adjust itself given the nature of the running program? 14:51
jnthn *nod* 14:52
timotimo something the nimrod developer told me is that for things like video games, you tend to have a spot in your run where the stack is super small and the number of alive objects tends to be at a local minimum, which is, for example, at the end of a main loop iteration 14:55
brrt is 435476 LoC still a 'small vm'? :-) 14:56
timotimo would it be interesting to expose the "set the GC-please-flag" operation as an nqp:: op to moarvm programs?
brrt (it probably is :-))
timotimo something that makes me jealous is that the pypy people can just "plug in" a different GC, as the root finding code is generated at translation-time 14:57
so they recently were like "hey let's use an incremental GC instead" and "just" did it
jnthn brrt: I'm hoping you didn't count 3rdparty... :) 14:59
brrt oh... maybe haha 15:06
oh, that is 10.000 lines or so
much smaller
no, 105.000 lines
not my best day today
anyway, off for dinner :-)
15:07 brrt left 15:25 LLamaRider joined 15:34 lizmat joined
timotimo i bought an ergonomic keyboard 15:35
feels nice under my hands, i hope it makes a good difference
typing on it already works fine it seems 15:36
jnthn :) 15:37
good keyboards are a wrothwhile investment
hah, worthwhile
15:43 lizmat joined
timotimo aye 15:45
15:45 woolfy joined
timotimo annoyingly, with the newest kernel and/or xorg and/or synaptics driver, the sensitivity of the touchpad in my laptop is no longer adjustable ... it's stuck on the lowest setting i can imagine ... 15:50
oh btw
"MJ" is a funny choice for MVMJit 15:51
but Moar is also already a funny word
i wonder if we want to touch on that subject?
16:08 vendethiel joined
jnthn Just pushed a patch that seems to make async http server somewhat more stable on Moar 16:21
(In conjunction with other patches earlier.) 16:22
lizmat reason to bump MOAR_REVISION? 16:27
16:36 jnap joined
btyler jnthn: subjected a fresh moar to some wrk: gist.github.com/kanatohodets/46c83...e-moar-wrk 16:40
with multiple connections it tends to segfault, but more descriptive errors occur with a single thread/single connection coming from wrk
one single connection/single thread run did complete (default is 10 seconds), at about 40 requests/second :) 16:41
jnthn I guess that's an improvement over before, then... 16:43
btyler emphatically so -- it couldn't complete 10 seconds on any settings
*previously 16:44
jnthn *nod*
timotimo how long does it survive now? 16:45
btyler as a point of reference, same settings on wrk going after a similar server in mojolicious (just spitting back 'hello world') hits about 320 requests/second on my machine
timotimo: race-y, so it varies
jnthn m: say 320 / 40
camelia rakudo-moar 77024f: OUTPUTĀ«8ā¤Ā»
timotimo ah
jnthn Some work to go, but at least it's a single digit factor :) 16:46
timotimo can i get an url to link to for the script that's being torture-tested?
_sri btyler: is your box very very slow? 320 rps is not much at all
btyler _sri: single connection single thread
from wrk
timotimo: github.com/tony-o/perl6-http-serve...ter/ab.pl6 16:47
timotimo thanks
btyler _sri: when I use more normal settings (2 threads, 10 concurrent connections against hypnotoad on default settings) I get closer to 1.1k req/s 16:48
but perl6-m isn't ready for that kind of assault just yet :) so I wanted to keep things loosely comparable
_sri btyler: wow, still quite slow
btyler _sri: perhaps EV isn't triggering; it's a 2010 MBP, so not terrible, but not amazing 16:49
_sri on my little macbook air i get 914 rps with the same wrk settings running against the single process daemon
make sure you're running in production mode, if you're using a server other than hypnotoad 16:50
full hypnotoad with good settings gets me roughly 2k rps
with the hello world app we use for profiling github.com/kraih/mojo/blob/master/...s/hello.pl 16:51
timotimo what is EV? 16:52
_sri libev binding
i so wish i could switch to libuv with mojolicious...
timotimo ah 16:53
btyler _sri: running a comparable app helps, heh. 1.6k now. setting libev kqueue flags doesn't seem to make a difference. 800 single thread/single connection from wrk 16:55
the ab.pl6 script could probably use a closer look as well
jnthn time for shopping, dinner, etc. bbiab 16:58
_sri :)
17:11 FROGGS joined
FROGGS $ perl6-m -I. --target=mbc --output=Bar.moarvm -e 'sub EXPORT(|) { my %h = baz => Buf.new(0 xx 10); %h }' 17:37
$ perl6-m -I. --target=mbc --output=Foo.moarvm -e 'use Bar'ā¤===SORRY!===ā¤MVMArray: Unhandled slot type
jnthn: that is my Archive::Tar bug
it happens in MVMArray.serialize btw 17:52
17:53 colomon_ joined
FROGGS ahh, that is an MVM_ARRAY_U8 slot_type 17:55
17:55 woolfy left
FROGGS okay, seems easy 17:56
Ć³.Ć² 18:01
Compiling lib/Archive/Tar/File.pm to mbc
Missing serialize REPR function for REPR VMException
golfed down to this: gist.github.com/FROGGS/8da00dbd8df5895d96b1 18:33
compile that to Bar.moarvm, and try to compile a Foo.pm that uses Bar
this happens in serialization.c serialize_object() 18:36
jnthn FROGGS: you manged to fix the other one? 18:43
FROGGS the first one, yes
jnthn: it was like you said, just a NYI :o)
dunno what to do about this one though... because I don't think I really want to serialize a VMException 18:44
jnthn As to the second one...how on earth does it end up wanting to serialize an exception... 18:45
FROGGS something must be garbage in there...
because removing either line 5 *or* 6 makes it not explode 18:46
valgrind shows nothing sadly
jnthn %EXPORT<&BLOCK_SIZE> = { my $n };
%EXPORT<&BZIP> = do { try require ENOCAKE; +not so $! };
FROGGS and I am unable to break at that exception in gdb
jnthn So, that closure there closes over the $!
Which I guess points to the VMException 18:47
FROGGS can I make it lexical?
jnthn Well, what if before returning %EXPORT you do $! = Any or so? 18:48
FROGGS that seems to fix it...
hold on
jnthn That'll tell us if we know the issue...
FROGGS both helps
btyler hmm, I wonder if the async http server implmentation is working as intended. perl6-m survived 10 seconds with 2 threads and 10 connections, but the throughput was the same as when wrk used 1 thread and 1 connection (~40 reqs/second) 18:49
jnthn btyler: I didn't really look at the impl, I just worked on making things not explode :) 18:50
btyler jnthn: right right :) I was just thinking that maybe I should try hacking up a simpler test script
FROGGS okay, I just make that $! lexical, that is what I wanted anyway 18:59
timotimo does it "start" at all? because there's still only one thread where event loopy things are handled
jnthn timotimo: That thread just tosses things into the queue, and other threads can handle them 19:00
timotimo oK 19:01
TEST this shift key feels weird
WHAT WHAT
=** +{) [{[{[{ 19:02
at least that works
FROGGS Missing or wrong version of dependency 'lib/Compress/Zlib/Raw.pm6' 19:20
^--- require-ing it seems not to be the best thing atm
19:27 vendethiel joined
timotimo maybe "require" doesn't trigger compilation? 19:40
jnthn Well, require + precomp is a small disaster if you aren't really careful 19:41
FROGGS Compress::Zlib::Raw was freshly precompiled
I am require-ing Compress::Zlib btw, which uses the ::Raw which uses NativeCall 19:42
jnthn Yes, the "missing" is the key bit there.
ah, well, that's stranger... 19:43
FROGGS RAKUDO_MODULE_DEBUG=1 show that the right modules got loaded btw
(the .moarvms) 19:44
timotimo unfortunately we can hardly tell "missing" and "wrong version" apart 19:45
also we still don't know which module causes the problem
if A uses B and B uses C and the later step blows up, there's no way to tell it's B in the middle.
FROGGS $ perl6-m -I. --target=mbc --output=Foo.moarvm -e 'if 1 { require Baz; say ::("Test") }' 19:55
$ perl6-m -I. -MFoo -e1
(Test)
not that easy to recreate...
will golf the original files down now
timotimo is there some way we can later make moarvm's garbage collector pauses shorter? or would that require basically replacing the Gc? 19:56
FROGGS you'd have to make it faster to have shorter pauses 19:57
timotimo hah
that doesn't scale :)
jnthn: do you think it'd make any sense at all to (at least mildly) sort the work list of pointers by address? 20:04
jnthn Are pauses actually a problem at present? 20:21
Sorting by address sounds really odd. 20:22
timotimo just a shot in the dark
i didn't actually measure common pause times
jnthn At the moment it works like a stack
timotimo i don't have a workload yet that would need very short pauses
jnthn There's actually a common in worklist.h, iirc, that mentions this.
timotimo (because in general we're a bit too slow to be doing things like that anyway)
jnthn *comment
timotimo oke 20:23
jnthn Where "bit too slow" means "tadzik++ runs 60fps games" :)
timotimo heh
jnthn I don't *remember* hearing pause times were an issue there.
timotimo well, the game he's running is thoroughly simple, to be fair 20:24
jnthn Sure :)
timotimo we're not pumping vertex data into the graphics card, or calculating particle systems or anything like that 20:25
jnthn BTW, given I improved inline and fixed opt of for (1..100000) { } it may be worth doing another benchmark update... 20:27
May show something nice for the for-using ones.
timotimo was that after the last benchmark run i posted? 20:28
because i linked that in the weekly
jnthn Yeah 20:29
Your last one did OSR I think
Oh, maybe some of the inline improvements too
timotimo i think osr + an inlining fix
jnthn I know postfix:<++> couldn't be inlined until after it, though...
timotimo i'm not sure if i have the return handler elimination stuff in there 20:30
jnthn Darn, my small scripts doing lots of threads now seem to not easily SEGV a Moar with a small nursery 20:32
Guess I have to move up to bigger examples.
timotimo darn, we're stable enough for small things now! 20:33
jnthn wtf, it creates enough CPU load that my music just skipped 20:34
timotimo could be memory load, too? 20:35
or disk busyness?
jnthn Shouldn't be using diks at all...
timotimo hmm, maybe it's making the computer swap? :) 20:36
jnthn And no, using 150MB or so
(or RAM)
timotimo huh.
jnthn It was using all the CPU it could lay its hands on :)
OK, enough thread bug hunt for today. Time to look at one other thing... :) 20:37
timotimo i'll get rid of some background processes on my desktop and then i'll run another rakudo benchmark
i see it updated nqp_revision somewhat recently
you're going to quickly rewrite our string handling? ;)
jnthn urgh 20:38
timotimo sorry :)
jnthn No, but I should do that at some point... 20:39
No, gonna put in the role type var opt, I think 20:40
timotimo sounds neat. i'll be interested to see what it does 20:41
jnthn Mostly, just exploits the insight that in a method in a role, $!foo is currently unoptimization because we have to look up the class handle 20:42
But if you specialized by the invocant type already then it's actually a constant within the specialization.
timotimo ah, sounds good 20:49
that would get compile_time_value and annotation quite often, wouldn't it?
jnthn Well, I was thinking primarily about Cursor... 20:50
timotimo oh, cursor
well, if it optimizes access to stuff there, that'd be quite fantastic
jnthn At the moment !cursor_start, !cursor_capture, and so forth get no opt of the attribute access
timotimo is that all?
don't we have problems in general in cursors because our matching class is a bit indirect?
jnthn Indirect? 20:51
timotimo er ... 20:58
i *think* we're doing nqp::bindattr with runtime-valued strings?
or something like that?
it occurs to me now that that wouldn't be helped by an opt that targets roles 20:59
t.h8.lv/p6bench/2014-06-30-stuff.html 21:01
FROGGS I'd think that optimizing CAPHASH would help a lot, but I'm not able to profile that 21:02
timotimo the differences are now much more pronounced
in all the earlier benchmarks at least
er... the upper benchmarks
jnthn gets typevar scope in place, and starts looking at optimizing it. 21:16
21:17 brrt joined
brrt \o #moarvm 21:18
timotimo heyo brrt
brrt timotimo: the touchpad thing is a known issue
timotimo how are you feeling today?
FROGGS hi brrt
timotimo ah! do you know where i can follow that bug around?
brrt i think so
you're using fedora, or not?
timotimo i am
brrt :-) 21:19
bugzilla.redhat.com/show_bug.cgi?id=1104789
jnthn missing dalek again :(
brrt here you go
bugzilla.redhat.com/show_bug.cgi?id=1104789#c20 is thef ix 21:20
i'm... feeling ok, i guess
:-) had some time to clear my thought
s
timotimo thank you for the pointer 21:24
the pointer for fixing my pointer
jnthn brrt: Got some ideas on the JIT cleanups you were plotting? 21:26
oh wait, you might have already pushed them and there was no dalek to say so...
brrt no, haven't pushed them yet 21:28
and yes, have ideas :-)
timotimo brrt: have you already tried building an nqp (and maybe even a rakudo) with the jit branch?
brrt yes, of course, and that works :-)
21:29 lee_ joined
brrt i.e., if it doesn't work now, somethings is broken that i don't know yet 21:29
FROGGS can confirm that
timotimo wow.
jnthn brrt: May be worth merning in latest master at some point, thanks to various things that have landed of late :
21:29 tadzik1 joined
timotimo aye, latest master does get lots more chances at speshing 21:29
and inlining
21:29 jnap1 joined
jnthn brrt++ # keeping it building NQP and Rakudo, so there won't be an epic bughunt later 21:29
brrt :-)
jnthn That's a very wise thing to do. 21:30
brrt building nqp was how i found out about the.... ahem... whatwasitcalledbug
anyway, very annoying bug i fixed last week
jnthn Oh...inline...
21:30 cxreg2 joined
brrt oh, that, yes :-) 21:30
brrt is greatly fond of make -j these days 21:31
jnthn Yes, sorry you had to share in the pain of inline...
I'm hoping we've got things structured so that JIT + inline + deopt isn't actually any more work than just getting JIT + deopt working...
brrt no problem :-) expectations change,that is all
jnthn ...at least, that's what I've tried to achieve. 21:32
brrt as i recall, deopt was a function call and jump to exit, right?
jnthn Well, I think we'll get you to pass an index in too
But yes, function call passing that index, let it do the work, then exit. 21:33
brrt yes, but the index was hardcoded iirc
jnthn Right, it's a constant
That you get from ann.
brrt hmm, my JIT of wval isn't apparantly totally correct 21:36
21:36 cognominal joined
brrt whut 21:37
*ahum*
spot the bug: github.com/MoarVM/MoarVM/blob/moar...jit.c#L195 21:40
timotimo i suppose you meant to get the two properties of the .reg? 21:41
because an operand is either a register or a literal, but not both?
jnthn [0] :)
timotimo oh
you probably wanted the next arg, yeah
oops :S
quite similar to the bug in isconcrete
jnthn And right below too
MVMint64 idx = idx = ins->operands[0].lit_i64;
Wants to be 2 21:42
brrt precisely :-) 21:43
but fixed now
brrt is off for tonight and will hopefully do better tomorrow 21:46
21:47 brrt left
timotimo :) 21:49
jnthn 'night, brrt 21:52
Time for some rest...'night o/ 22:49
22:55 bcode joined
timotimo gnite jnthn 23:09
23:13 jnap joined
timotimo i do look forward to the merge master -> moar-jit 23:27
merge or rebase, whatever fits best 23:28
23:30 bcode_ joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!