dalek p: ce126b6 | (Zoffix Znet)++ | docs/ops.markdown:
Fix not_i's name in ToC and heading
 01:25
ast: 31ce7c1 | MasterDuke17++ | S12-introspection/attributes.t:
Tests for RT #77070
 01:36
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=77070
dalek rakudo/nom: a8ba26b | (Zoffix Znet)++ | src/core/Num.pm: 03:02
rakudo/nom: Make infix:<..> on Nums 13x faster + fix native num NaN ===
rakudo/nom:
rakudo/nom: And anything else that uses === on Nums should be faster too.
rakudo/nom: jnthn++ for finding the cause of slowdown.
rakudo/nom:
rakudo/nom: The presence of &infix:<===>(NaN, NaN) candidate prevents
rakudo/nom: caching[1], which causes massive slowdown in infix:<..> on Nums.
rakudo/nom: The candidate also does not handle native nums as they go to a
rakudo/nom: narrower candidate, so NaN === NaN is broken too.
rakudo/nom:
rakudo/nom: Fix by removing (NaN, NaN) candidate and adding a check for NaNs
babydrop 0 into other candidates. Any num but NaN is less-or-equal to positive 03:03
infinity, so use that as an `nqp::isnan()` check.
Fixes RT#130190: rt.perl.org/Ticket/Display.html?id=130190
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130190
babydrop
[1] irclog.perlgeek.de/perl6/2016-12-09#i_13713052
github.com/rakudo/rakudo/commit/a8ba26bbe
dalek ast: e6b125e | (Zoffix Znet)++ | S02-types/nan.t:
Test === works on native num NaNs

Bug finding: irclog.perlgeek.de/perl6/2016-12-09#i_13713101 Fix commit: github.com/rakudo/rakudo/commit/a8ba26bbe		 03:04
babydrop hmmm 03:10
babydrop was just thinking about whether our 42 Easter Egg is affecting performance, if `where`s prevent caching and it got a literal for the invocant... 03:13
don't think so... changed it to multi method WHY { dd 'in it'; 42 } and ran if you tests, never printed that string 03:17
Too bad, 'cause that would be both awesome and embaracing. 03:18
.oO( how did I manage to write `if you` for `a few` :o )
samcv babydrop, would it be okay if I added a 'uniprops' sub? it was in the synopsis 04:47
and we have 'uninames'
so i think makes sense to have a uniprops sub
m: multi sub uniprops(Str:D $str, Stringy:D $propname = "GeneralCategory") { $str.NFC.map: { uniprop($_, $propname ) } }; say uniprops "string" 04:48
camelia rakudo-moar a8ba26: OUTPUTĀ«(Ll Ll Ll Ll Ll Ll)ā¤Ā»
samcv m: multi sub uniprops(Str:D $str, Stringy:D $propname = "GeneralCategory") { $str.NFC.map: { uniprop($_, $propname ) } }; say uniprops "string123", 'Alphabetic'
camelia rakudo-moar a8ba26: OUTPUTĀ«(1 1 1 1 1 1 0 0 0)ā¤Ā»
lizmat morning #perl6-dev! 09:46
is it me, or don't we have an advent post for today yet ?
gfldex lizmat: DrForr had internet woes 09:53
lizmat ok 09:54
jnthn samcv: Having uniprops to go with uninames and ords makes sense, I think 10:53
yoleaux2 9 Dec 2016 23:47Z <MasterDuke> jnthn: re method caching with wheres. i looked through src/Perl6/Metamodel/BOOTSTRAP.nqp a bit, but couldn't figure out why/where/how where clauses precluded caching. do you happen to have the next level pointer at hand?
jnthn .tell MasterDuke it's controlled by $pure_type_result which is zeroed if the candidate's info has has the constrainty key, which is in turn set inside of !sort_dispatchees_internal 10:56
yoleaux2 jnthn: I'll pass your message to MasterDuke.
dogbert17 hmm, today t/spec/S32-io/socket-recv-vs-read.t has started to fail ;( 11:20
seems to be test #03 - recv char count is not lower limit (chars) 11:26
*** Error in `/home/dogbert/repos/rakudo/install/bin/moar': double free or corruption (fasttop): 0x428608f0 *** 11:28
jnthn That one also showed up in the handful of tests that had issues when run with small GC nursery 11:33
gfldex m: class C { method m {} }; say &C::m.WHAT 11:39
camelia rakudo-moar a8ba26: OUTPUTĀ«(Any)ā¤Ā»
gfldex why is that Any?
dogbert17 jnthn: how can I change the nursery size? 11:40
jnthn See my recent blog post
gfldex: Because methods are has-scoped by default
dogbert17 :-)
gfldex i c
jnthn (So, they're only installed in the meta-object)
Pretty sure if you stick an our on it, it'll be package-visible 11:41
Or look it up with C.^lookup('m')
gfldex m: class C { our method m {} }; say (&C::m).WHAT
camelia rakudo-moar a8ba26: OUTPUTĀ«(Method)ā¤Ā»
gfldex m: class C { our method m {}; method n { $.m } }; say C.new.n 11:45
camelia rakudo-moar a8ba26: OUTPUTĀ«No such method 'm' for invocant of type 'C'ā¤ in method n at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
gfldex that's at least LTA
(and used to work)
MasterDuke bisect: class C { our method m {}; method n { $.m } }; say C.new.n 11:48
yoleaux2 10:56Z <jnthn> MasterDuke: it's controlled by $pure_type_result which is zeroed if the candidate's info has has the constrainty key, which is in turn set inside of !sort_dispatchees_internal
bisectable6 MasterDuke, Bisecting by output (old=2015.12 new=a8ba26b) because on both starting points the exit code is 1
MasterDuke, bisect log: gist.github.com/eeebf40c2986157ff5...c426b55a3e
MasterDuke, (2016-09-27) github.com/rakudo/rakudo/commit/22...0f14b9c05c
dogbert17 ok, with 32k nursery I can get it to segfault intermittently 11:49
psch committable6: 2015.11 class C { our method m {}; method n { $.m } }; say C.new.n
committable6 psch, Ā¦Ā«2015.11Ā»: Method 'm' not found for invocant of class 'C'ā¤ in method n at /tmp/WBrd_OMaBs:1ā¤ in block <unit> at /tmp/WBrd_OMaBs:1ā¤ Ā«exit code = 1Ā»
psch m: 2015.11 class C { our method m {}; method n { self.m } }; say C.new.n 11:50
camelia rakudo-moar a8ba26: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Two terms in a rowā¤at <tmp>:1ā¤------> 2015.11ā class C { our method m {}; method n { sā¤ expecting any of:ā¤ infixā¤ infix stopperā¤ statement endā¤ statemenā€¦Ā»
psch ehh
m: class C { our method m {}; method n { self.m } }; say C.new.n
camelia rakudo-moar a8ba26: OUTPUTĀ«No such method 'm' for invocant of type 'C'ā¤ in method n at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
dogbert17 jnthn: here's a gist of the fault in t/spec/S32-io/socket-recv-vs-read.t (32k Nursery): gist.github.com/dogbert17/a73858a3...21585ef345 11:51
gfldex it used to work a few weeks before 6.c 11:54
psch committable6: 2015.09 class C { our method m {}; method n { $.m } }; say C.new.n
committable6 psch, Ā¦Ā«2015.09Ā»: Method 'm' not found for invocant of class 'C'ā¤ in method n at /tmp/1djno0ZfK3:1ā¤ in block <unit> at /tmp/1djno0ZfK3:1ā¤ Ā«exit code = 1Ā» 11:55
psch committable6: 2015.02 class C { our method m {}; method n { $.m } }; say C.new.n
committable6 psch, Ā¦Ā«2015.02Ā»: No such method 'm' for invocant of type 'C'ā¤ in method n at /tmp/01_jgTSXpg:1ā¤ in block <unit> at /tmp/01_jgTSXpg:1ā¤ Ā«exit code = 1Ā»
psch no idea
gfldex should it work? 11:56
psch i'm not sure. our installs lexically, has installs in the method cache
i don't think we want 'method' to always install in the method cache, because we might not have one
MasterDuke committable6: all class C { our method m {}; method n { $.m } }; say C.new.n
nine Question for the doc people: can we include gist.github.com/niner/70f7b46eefb7...6bea11efeb somewhere? 11:57
committable6 MasterDuke, gist.github.com/6620aebb12a61cfc38...cf74acf232
MasterDuke doesn't seem to have worked as far back as 2014.01 (the oldest tag built for the *ables) 11:58
gfldex nine: please file a doc issue on github and state what this change depends on (I take it this rakudo branch wasn't merged yet) 11:59
nine: that change has to be documented but only after the next proper rakudo release 12:00
we didn't pay much attention to that in the past because so many bugs got fixed but at some point we will have to 12:01
maybe even have branches for the docs themself so we can prepare doc changes alongside language changes
dogbert17 any git wizards out there 12:03
gfldex m: class C { our method m { say 'foo' }; method n { C::m(self) } }; C.new.n
camelia rakudo-moar a8ba26: OUTPUTĀ«fooā¤Ā»
nine gfldex: github.com/perl6/doc/issues/1043 12:04
gfldex: I'll link my gist directly in the pull requests I submit until it's included in the docs. 12:05
dogbert17 if I go to my rakudo repo and then give the following cmd's: cd nqp/MoarVM; git log --oneline # I get the following
d2139b52 Fix pow_I when it takes an exponent larger than 2**32.
2025f863 Provide a #define for deopt logging.
22281b63 Provide a way to disable dynlex caching.
where's jnthn's clear dynlex cache fix? 12:06
lucasb m: class C { my method m { say 'foo' }; method n { m(self) } }; C.new.n 12:07
camelia rakudo-moar a8ba26: OUTPUTĀ«fooā¤Ā»
lucasb so, 'my method' and 'our method' works more like subroutines?
jnthn Subs and methods (and submethods, and regexes/tokens/rules) are all types of Routine 12:08
psch lucasb: the only differences between a sub and a method are the implicit self in method and the different default scope
lucasb yes, I understand
psch well, user-facing differences probably
lucasb my point is: should 'my method' and 'our method' be valid syntax?
jnthn Sure, why not?
my regex ... is valid syntax
And a regex is just a method whose body is written in a different language 12:09
It can also be useful in conjunction with .&foo
And potentially during meta-programming too
my method blah() { ... }; $class.^add_method('blah', &blah);
lucasb ah, ok. I was confused. but I now I see it has its use case
jnthn lunch & 12:10
lucasb thanks
gfldex jnthn: are EXPORTHOW (and DECLARE) an implementation detail? (I would favour "yes" as an answer. :->) 12:14
also, is there something similar for custom declarators akin to `method`?
psch doesn't DECLARE do that? 12:18
i mean, you just have to supply different Actions
gfldex EXPORTHOW and DECLARE are ENODOC 12:20
psch ...or does DECLARE just link a HOW to a declarator?
i'm really not sure about those :/
babydrop Anyone got their Advent post ready already and can post today? 12:30
" DrForr ā”‚ babydrop: (or anyone) I have no 'net connection. I can do 20th-24th because I'll be be back home." 12:31
oh
babydrop lols at `# your ad here` in source 12:36
tbrowder babydrop: Mine is basically ready AFAIK, but I am waiting for [Coke]'s review. All it needs is the day change 10 vs. 12. 12:49
babydrop tbrowder: turns out someone already posted for today
tbrowder whew!
babydrop I just saw a /msg for DrForr and started panicing :)
lizmat is it expected that perl6-debug-m complains about Debugger::UI::CommandLine not being installed? 13:09
is it expected there is no perl6-debug, only a perl6-debug-m ?
lizmat started proofreading the chapter about the debugger in Laurent's book
timotimo it is expected that it complains about the CommandLine not being installed 13:11
you have to get it from the ecosystem
i expect it comes with rakudo star, though
whichis, iirc, what laurents book recommends you get 13:12
lizmat hmmmm... ok
not sure why it shouldn't just be part of the core...
I mean, if the debugger is useless without it
why include the debugger then? 13:13
(yes, I know why, but playing devil's advocate)
timotimo it's useless without *some* UI module :)
ideally, we'll get a GTK-based one in the future, because that'd make it easier to handle multi-threaded programs
lizmat ok, I get that, but why not include *a* CommandLine module in the mean time? 13:14
timotimo also, that module depends on ASCIIColor, among other things
sorry, ANSIColor
so will that go into core, too?
lizmat perhaps, unless its use of it is minimal and we can extract the logic into the core version
timotimo it could probably be done 13:17
i mean, in general you can just implement "colored" and "color" as "return first argument" and "return empty string"
lizmat_ it's just that I hadn't realized before that we're shipping rakudo with an incomplete debugger 13:19
lizmat only a perl6-debug-m (when just building for moar) 13:20
timotimo: also, why is there no perl6-debug ?
(repeating lines that got lost in the ozone)
timotimo i don't know. oversight in the makefile?
lizmat (not necessarily in the correct order) 13:21
ok, so no conscious decision
jnthn The bit that's in core is the bit that is an utter pain to maintain out of it (e.g. the actual compiler binding itself). 13:41
And yes, the idea is that a distribution will include some frontend that provides a useful UI, and that you can upgrade that part independently of your compiler version. 13:42
timotimo obviously our module installing stuff should make it possible to just say "hey i want the latest version of that" and panda or zef would say "yup, here you go" 13:43
dalek kudo/nom: c04b8b5 | moritz++ | src/core/Match.pm:
Corect Match.prematch and Match.postmatch for zero-width matches, ufobat++
 13:46
ast: 7530a15 | moritz++ | S05-capture/match-object.t:
Test for .prematch and .postmatch on zero-width matches
 13:50
kudo/nom: 20cfab3 | moritz++ | docs/ChangeLog:
Add changelog entry
 13:51
MasterDuke i apologize because i think i've asked this before but forgotten the answer. is there any one particular thing that makes reading a file line by line (e.g., perl6 -n) so slow compared to perl5? 13:54
e.g., for a 13million line file, time perl -ne '' takes 1.7s and time perl6 -ne '' takes 1m26s 13:56
timotimo like, with just an empty -e?
interesting
you could ask a c-level profiler like perf about it
MasterDuke yeah, about to do that
timotimo how much faster does it get when you say you want latin1 encoding?
MasterDuke how do i do that?
timotimo i don't think you can do it with -n
MasterDuke i'm perf recording -n now, will try an explicit open and lines with latin1 after 14:00
12.62% moar libmoar.so [.] MVM_interp_run 14:01
9.51% moar libmoar.so [.] MVM_string_utf8_decodestream 14:02
timotimo i recommend using -g with perf record and report
dalek kudo/nom: b9e2ffa | lizmat++ | src/core/multidim_slice.pm:
Make @a[2;2] about 40% faster

By assuming that the @indices have always already been reified completely. I haven't been able to come up with a way to not have them reified (other than calling postcircumfix:<[; ]> directly). So the assumption seems safe, for now at least. Please revert if this causes some ecosystem fallout, spectest itself is clean.		 14:04
timotimo wow, 40% is pretty amazing
dalek kudo/nom: 2bef4d3 | moritz++ | src/core/Match.pm:
Simplify Match.{pre,post}match
 14:13
lizmat to make things even faster, I'm thinking about creating postcircumfix:<[;]>(\SELF, \one, \two) candidates 14:15
the optimizer should then rewrite the generic code to those cases
afk, connection is getting too flaky in the car 14:16
MasterDuke timotimo: all the things that were red in the report expanded out: gist.github.com/MasterDuke17/03647...5f1af056c6 14:18
timotimo oh, you may be interested in learning about perf report -g --stdio :) 14:20
tbh, that doesn't tell me very much :\ 14:22
MasterDuke would adding --stdio help? 14:23
oh, that's for the report 14:24
this was using a moarvm built with --debug=3, any other options to get more useful info? 14:25
to moar and/or perf? 14:26
timotimo well, the JIT gives us frames that don't show up in any sensible manner in the profiler 14:29
MasterDuke i'm trying '--call-graph dwarf' for perf 14:30
timotimo: gist.github.com/MasterDuke17/d8ee3...78dacbb13e 14:42
timotimo tbh, i'm no good at reading the uncollapsed view :| 14:44
tbrowder .tell [Coke] I'll be off the normal land-locked internet grid for Advent editing for a few hours while traveling. I just made some minor changes to the ending words and format. I will be monitoring IRC as well as my iPhone and cell carrier can handle it. 14:45
yoleaux2 tbrowder: I'll pass your message to [Coke].
dogbert17 I have now run 'make spectest' with a small nursery, there are two failures, i.e. t/spec/S17-supply/syntax.t and t/spec/S32-io/socket-recv-vs-read.t 14:48
it could be worse I guess 14:50
I haven't seen this before: MoarVM panic: Internal error: Unwound entire stack and missed handler
MasterDuke timotimo: if you reload the gist there's a file at the end with the collapsed view
timotimo hm, does it allow you to sort by exclusive rather than inclusive time? 14:52
MasterDuke timotimo: i added a file with --no-children, does that do what you're looking for? 14:57
timotimo let's see?
hm. it could be what it calls "overhead" is what i'm looking for 14:58
so going by that we have 8% of utf8 decoding and 4.5% of looking for newline characters 14:59
frame-related overhead comes in at a lot, though
like, invocation and returning
GC is basically free at this point 15:00
MasterDuke fyi, i should be pretty close to HEAD for moar+nqp+rakudo
timotimo right 15:01
can you test the difference between latin1 and utf8, then? 15:02
MasterDuke latin1 was about 40s faster according to time, will start a perf record
timotimo where were the original numbers? with the perl5 number in addition? 15:04
oh, there it is
but 40s faster than 1m26s is already only 46s
so using latin1 is basically 2x faster
MasterDuke timotimo: gist.github.com/MasterDuke17/4ea0d...6ac6ffe650 15:05
timotimo --no-children please? :) 15:07
MasterDuke done
timotimo okay, so does anybody want to make find_separator and latin1_decodestream faster? :P 15:08
the memset is probably from where we zero out the memory a frame gets 15:09
it's potentially not so good that it's unaligned, but i've tried to make it aligned in the past and failed
and invocation-related overhead is a big issue here
MasterDuke does it mean anything that the top line for -n was "11.34% moar libmoar.so [.] MVM_interp_run", vs find_separator and latin1_decodestream for setting the encoding to latin1? 15:20
timotimo oh, interesting point 15:22
clearly the code we generated for the -n -e '' was not nearly as optimal as the code you wrote manually
MasterDuke -ne '' is 1m slower than -e 'my $fh = open("compile.sql"); for $fh.lines() {}' 15:31
dalek kudo/nom: bfe4abb | timotimo++ | src/core/Match.pm:
fix accidental creation of lists in prematch and postmatch
timotimo whoa, holy fuck
one whole minute
MasterDuke maybe even closer to 1m10s 15:32
timotimo er 15:33
but isn't -ne '' just 1m26?
how can 1m10s be 1 minute slower than 1m26s?
MasterDuke i'm now running on my computer, i think the previous numbers are from AlexDaniel's server 15:34
timotimo oh
i don't have a good file for this
MasterDuke you have access to his server right?
timotimo oh, of course
how big exactly is this file?
MasterDuke 740m uncompressed, 42m compressed 15:35
/home/bisectable/git/rakudo_masterduke17/compile.sql
compressed is /home/bisectable/git/rakudo_masterduke17/compile.sql.zst 15:36
timotimo downloading it nao
you know what package i need to get to unpack zstandard? 15:37
oh, clearly zstd
MasterDuke btw, that's the profile-compile output as sql for building rakudo 15:41
timotimo ah
i thought so
right, with the manual -e we get 20% time spent inside utf8_decodestream 15:42
do we have to do something special to make perl5 also do utf8 stuff?
and another 8% of time spent looking for separators 15:43
babydrop perl -C 15:44
(perldoc perlrun)
timotimo makes absolutely zero difference 15:46
so it must already have been doing utf8 parsing
[Tux] This is Rakudo version 2016.11-178-gbfe4abb14 built on MoarVM version 2016.11-44-g8e24145d 15:47
csv-ip5xs 3.092
test 14.202
test-t 6.270
csv-parser 14.843
MasterDuke time perl -e 'use open ":std", ":encoding(utf-8)"; open my $fh, "compile.sql"; while (<$fh>) {};' takes 15s
and 2s without the use open ":std", ":encoding(utf-8)"; 15:48
same as -ne ''
timotimo btw, it should be much faster to .slurp-rest.lines 15:52
huh, interesting 15:53
that now uses string_find_cclass and unicode_codepoint_has_property_value are both at 15% time used
and decodestream is at 26% time used
MasterDuke that won't read the whole file into memory?
timotimo it will
hm. not that much faster 15:54
slurp-rest.lines is at 26s, lines only is at 37s
11s for your perl5 oneliner with :std 15:55
whatever :std means
dalek ast: 99a9bd8 | moritz++ | S05-capture/match-object.t:
Match.{pre,post}match should produce Str
MasterDuke slurp-rest.lines is 32s vs .lines is 50s for me 15:56
timotimo we're surely paying a bit for our stuff to be lazy 16:12
with slurp-rest, we might not want to, though?
MasterDuke 'my $fh = open("compile.sql"); while $fh.get {}' is only 33s vs 50s for 'my $fh = open("compile.sql"); for $fh.lines() {}' 16:16
where is -n implemented? it's not the easiest thing to search for 16:26
cygx MasterDuke: what about use nqp; my $fh := nqp::open("README", "r"); while $_ 16:28
= nqp::readlinefh($fh) { .print }
(without the linebreak, and compile.sql instead of README ;) 16:29
psch MasterDuke: Perl6::Actions::wrap_option_n_code
MasterDuke time ~/Source/perl6/install/bin/nqp-m -e 'my $fh := nqp::open("compile.sql", "r"); while nqp::readlinefh($fh) {}' is 22s 16:31
(same for readlinechompfh) 16:32
same if run using perl6-m and 'use nqp' 16:33
timotimo readlinechompfh being exactly as fast as readlinefh was a neat optimization we got at some point 16:51
babydrop woo \o/ test-t went down by 0.377 seconds \o/ 17:18
[Tux]: is the code that's run for test-t in the repo somewhere? I wanna run it locally
dogbert17 babydrop: github.com/Tux/CSV 17:32
timotimo i think he meant "where in the repo is that script?"
babydrop dogbert17: thanks! I guess it's the test-t.pl script 17:33
dogbert17 babydrop: I believe so (haven't tested it) 17:40
timotimo: lol, I should learn how to read 17:41
babydrop dogbert17: no, I didn't know about that repo. 17:45
dogbert17 babydrop: cool, maybe I can read after all :) 17:50
babydrop I can't write is the problem, it should be "in *a* repo" :) 17:52
dalek p: af3f6e3 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Implement nqp::ctxcode.
 18:04
p: dcfacd8 | (Pawel Murias)++ | t/nqp/079-callercode.t:
Test nqp::ctxcode.
ast: da6fde4 | Altai-man++ | integration/error-reporting.t:
Test for #125247 (#192)

  * Test for rt.perl.org/Public/Bug/Display.htm...et-history
  * Update test plan and narrow the test		 18:10
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125247
dalek p: 8090845 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (5 files):
[js] Use STables everywhere instead of Stables for more consistency.
 18:39
p: 9546d1e | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Implement nqp::fileislink.
p: 4db0734 | (Pawel Murias)++ | t/nqp/019-file-ops.t:
Test fileislink.
p: 9355d86 | (Pawel Murias)++ | t/nqp/019-file-ops.t:
Test a case when a stat ISLNK check is not true.
nqp: 18bb3af | (Pawel Murias)++ | src/vm/js/Operations.nqp:
nqp: Add :side_effects annotation to IO stuff I'm not sure if someone might use for side effects or that shouldn't be done twice.
kudo/nom: a34f0af | (Zoffix Znet)++ | src/Perl6/Actions.nqp:
Remove needless calls to infix:<,> in [sS]/// codegen

After a discussion[^1] and testing the output of old tickets[^2], it looks like these are no longer needed. After their removal, the bugs referenced by tickets do not re-appear and stresstest passes.
  [1] irclog.perlgeek.de/perl6/2016-12-10#i_13717904
  [2] irclog.perlgeek.de/perl6/2016-12-10#i_13718025		 20:42
kudo/nom: 772eadd | (Zoffix Znet)++ | src/Perl6/Actions.nqp:
Remove outdated comment
 21:00
kudo/nom: 164eb42 | (Zoffix Znet)++ | src/Perl6/Actions.nqp:
Remove useless p6store

We already do it a few lines above[^1]
  [1] github.com/rakudo/rakudo/blob/772e...7766-L7769		 21:16
kudo/nom: ea28845 | (Zoffix Znet)++ | src/Perl6/Actions.nqp:
Remove needless call to infix:<,> in [sS]/// codegen

One more needless call to remove for same reasons as those removed in github.com/rakudo/rakudo/commit/a3...b7682d663c		 21:56

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!