Geth roast: skids++ created pull request #329:
Add tests for RT#132006		 00:05
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132006
Geth roast: 6f7002f2c6 | skids++ | S02-types/instants-and-durations.t
Add tests for RT#132006
roast: 7edf35ddf7 | skids++ (committed using GitHub Web editor) | S02-types/instants-and-durations.t
Merge pull request #329 from skids/rt132006

Add tests for RT#132006
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132006
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132006
travis-ci Rakudo build passed. Nick Logan 'Use proper java 8 jdk package' 00:40
travis-ci.org/rakudo/rakudo/builds/278822303 github.com/rakudo/rakudo/compare/f...f339b91d2a
Geth roast: skids++ created pull request #330:
Rt126433		 00:50
roast: 90d40a449a | skids++ | S12-coercion/coercion-types.t
Re-attribute tests to RT#126433 and enhance them

One test was suceeding for the wrong reason
   throws-like does a dies-ok subtest so altering the test is ok
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126433
roast: 0d9b3e23d2 | skids++ | S12-coercion/coercion-types.t
Can do a todo here rather than a skip
roast: 574035ff4d | skids++ (committed using GitHub Web editor) | S12-coercion/coercion-types.t
Merge pull request #330 from skids/rt126433

Rt126433
lizmat Files=1229, Tests=75164, 314 wallclock secs (14.99 usr 5.30 sys + 2147.32 cusr 222.10 csys = 2389.71 CPU) 07:46
feels like we lost about 20 seconds wallclock since yesterday on the spectest
MasterDuke lizmat: how many tests have been added? 10:16
lizmat yesterdays: Files=1227, Tests=75115, 298 wallclock secs (14.64 usr 5.32 sys + 2016.98 cusr 210.03 csys = 2246.97 CPU) 10:18
so 49 tests
CPU usage is definitely also up
perhaps it's jnthn's new supply tests 10:19
timotimo at least the test doesn't hang on your system :)
lizmat indeed, does it on yours ?
timotimo yeah, S17-supply/syntax.t has a test that consumes infinite cpu and doesn't finish 10:21
MasterDuke some where for me a day or two ago, i'm doing a run now to see if it's changed
timotimo or was that changed?
lizmat dunno :-(
timotimo jnthn wasn't able to reproduce it
lizmat I guess /me neither :-( 10:22
timotimo the plot thickens. i won't be able to investigate very soon, though 10:27
dogbert11 compare with these times: irclog.perlgeek.de/perl6-dev/2017-...i_14928347 10:29
lizmat yeah, but almost 8K more tests 10:30
MasterDuke it is running pretty slowly, i also had a failure in t/spec/S32-io/IO-Socket-Async.t, `Parse errors: Bad plan. You planned 26 tests but ran 17.`
dogbert11 then those 8000 tests are quite slow 10:31
a few days later: irclog.perlgeek.de/perl6-dev/2017-...i_14961470
MasterDuke hm, that fails even when run by itself 10:32
looks like there's some debug output showing up 10:33
# host=::1
here with error
but then: Unhandled exception in code scheduled on thread 4
Unhandled exception in code scheduled on thread 7
Too few positionals passed; expected 6 arguments but got 2 10:34
dogbert11 MasterDuke: what happens if you disable the JIT 10:37
MasterDuke same errors, and same with disabling spesh also
dogbert11 interesting, it works for me and valgrind kept silent as well 10:38
MasterDuke do you see that debug output? 10:39
dogbert11 the host comments? 10:41
MasterDuke but yeah, neither gdb or valgrind are helpful 10:42
yeah, and 'here with error' i think
dogbert11 for '127.0.0.1', '::1' -> $host {
my $port = 5001;
diag("host=$host");
seems to come from the test file 10:43
MasterDuke github.com/rakudo/rakudo/blob/nom/...nc.pm#L201 10:45
maybe not the most useful error...
dogbert11 :) nice find
are you using gcc when building?
MasterDuke yeah, usually 10:46
gcc version 7.2.0 (GCC)
dogbert11 and you haven't been able to get asan working there?
MasterDuke i haven't tried recently, but couldn't get it in the past 10:47
how are you using it?
dogbert11 when using asan I tend to build MoarVM with 'perl Configure.pl --debug --no-optimize --asan --prefix=<install dir>' 10:48
that's almost enough
at least asan output should show up if a problem is encountered 10:49
MasterDuke do you have to --no-optimize? 10:50
dogbert11 no
MasterDuke hm, that spit out a bunch of leak info 10:51
dogbert11 what did you do
MasterDuke when i ran that test right after rebuilding with those options
lizmat afk& 10:52
MasterDuke but i tried rebuilding nqp and that failed
dogbert11 you don't have to rebuild nqp
MasterDuke well yeah, but why does it fail? is that expected? 10:53
dogbert11 let me try as well
dogbert11 rebuilds with 'perl Configure.pl --debug --asan --prefix=../../install/' followed by 'make -j6 install' 10:54
one thing which wont work is trying to run a prg compiled with asan under valgrind. Boom 10:55
MasterDuke oh hm, i didn't add --asan to the nqp configure 10:56
dogbert11 I only rebuild Moar with --asan
MasterDuke ok 10:57
dogbert11 perhaps we build our stuff differently
MasterDuke my usual MoarVM build: perl Configure.pl --prefix=/home/dan/Source/perl6/install/ --debug=3 --telemeh && make -j8 install 10:58
my usual NQP and Rakudo build: perl Configure.pl --prefix=/home/dan/Source/perl6/install/ && make -j8 install
dogbert11 here's what I do: 10:59
dogbert@dogbert-VirtualBox ~/repos/rakudo $ pwd
/home/dogbert/repos/rakudo
cd nqp/MoarVM
perl Configure.pl --debug --asan --prefix=../../install/ followed by make -j6 install and then 'cd -' and I'm good to go 11:00
btw, did you pick up a new system? Noticed the -j8 11:01
MasterDuke i have all three at the same directory level
dogbert11 aha 11:02
MasterDuke heh, not yet. -j8 is about the best value on this old system still
dogbert11 and now new Intel cpu's will be out in a couple of weeks 11:03
MasterDuke yeah, but they're expensive! 11:04
dogbert11 was afraid of that, then Ryzen is still on your radar I guess 11:05
MasterDuke i do plan to upgrade, but also just got new bindings for my snowboard and may have to get new boots also
dogbert11 $$$
MasterDuke yup 11:06
timotimo .o( use SportiveCall )
dogbert11 timotimo: are you good at interpreting callgrind results? 11:09
comparing results av a random spectest file, i.e. t/spec/S02-lists/tree.t, between 2017.07 and current 11:11
timotimo mildly
dogbert11 *of
the results are quite different, but of course a lot of work has been done in the meantime 11:12
timotimo fun: "bigfile".IO.slurp.lines is much better than "bigfile".IO.lines with regards to memory usage 11:14
MasterDuke ? 11:15
timotimo actually, the big impact comes when i .words every entry of the lines list afterwards 11:16
and take only the first one
dogbert11 timotimo: see anything odd here? gist.github.com/dogbert17/82ab9a5a...65d4dd4402 11:17
MasterDuke 120588maxresident with for IO.lines {} and 670020maxresident with for IO.slurp.lines {} 11:18
timotimo yeah
MasterDuke for a 57mb, 1million line file
dogbert11 wonders about the second line in the 'current release', i.e. 58,949,142 nqp/MoarVM/src/strings/ops.c:MVM_string_equal 11:19
timotimo i have 52 megs, 1264290 lines 11:21
did you also use a speshlog for this? %)
dogbert11 nope, should I have done that?
timotimo no
was just surprised the files were so similar :) 11:22
dogbert11 I might have messed up but I hope not :) 11:23
MasterDuke timotimo: wait, were you asking if i used a speshlog?
timotimo oh, haha 11:24
i didn't see dogbert answer instead of you 11:25
MasterDuke ha. but no, mine is the first 1million lines of the SQL output of profiling a rakudo build
timotimo dogbert11: yeah, the string equal thing is weird. we should perhaps grab a list of all moar-level stack traces from when that gets called, though that'll obviously give a gigantic file
maybe just the frame we're in when that happens 11:26
that could give us enough of a clue
dogbert11 callgrind_annotate does have a --tree option which supposedly can list the callers 11:27
timotimo right, but not the moar-level ones
have you ever used kcachegrind? 11:28
dogbert11 nope, would that do the job?
MasterDuke that's what i use 11:29
timotimo that gives you a prettier view of the whole thing 11:31
dogbert11 so it's a GUI
which seems to use KDE which I don't have :( 11:32
timotimo it doesn't "use kde", it should only use small parts
anyway, i'm grabbing all locations of MVM_string_equals calls and will count the individual places up to see what's what. 11:34
dogbert11 it crashed the first time but now it's seems to work
timotimo 225 megs so far %)
MasterDuke i bet you get over 1g 11:36
timotimo yeah, surely will 11:37
i have a feeling it'll take upwards of 15 minutes
oh, maybe i should use a moar compiled with --optimize=3 instead of --optimize=0 11:38
oh, okay, it already is
dogbert11 if I understand this correctly, not 100% certain, MVM_string_equal is called by bind_key, at_key, get_attribute, bind_attribute and MVM_frame_find_lexical_by_name 11:40
MasterDuke also directly called in interp.c by eq_s and ne_s 11:43
oh, do you mean when running your test file? 11:44
dogbert11 yeah t/spec/S02-lists/tree.t 11:45
MasterDuke ok, then nevermind what i said
btw, it's the host='::1' that my system doesn't like 11:47
TimToady waves from Tokyo
yoleaux 22 Sep 2017 19:43Z <Zoffix> TimToady: S02 says $? vars must not be changed after compile time; that makes $?USAGE kinda iffy, since we run all the sub MAIN bits at runtime. I'm thinking of changing it to $*USAGE on Sept 30th. Thoughts? IRC discussion: irclog.perlgeek.de/perl6-dev/2017-...i_15204296
22 Sep 2017 19:44Z <Zoffix> TimToady: worth clarifying: currently $?USAGE isn't available to users (so the change won't be breaking any code)
MasterDuke i bet it's because i disabled IPv6
TimToady Zoffix: I'm fine with $*USAGE
dogbert11 will read up on kcachegrind 11:53
Zoffix cool
MasterDuke huh, i guess everyone else has IPv6 enabled if i'm the only one getting that error 12:00
but either way, i don't think the test should diag("host=$host"), if anything it should put the $host in the individual test's descriptions 12:02
that was just added in github.com/perl6/roast/commit/8e38...887a42ee1, anybody object if i change it? 12:05
jdv79: ^^^
.ask jnthn is this github.com/rakudo/rakudo/blame/nom...nc.pm#L201 a debugging leftover? 12:08
yoleaux MasterDuke: I'll pass your message to jnthn.
timotimo MasterDuke: 2.9 gig so far 12:28
MasterDuke heh, any idea how far along you are?
timotimo no :( 12:29
the grep i have will have thrown out the "stage" lines
oh 12:31
i should be able to strace and see what function names it prints, the backtraces should contain the appropriate name of a stage in them
still stage parse 12:32
which isn't terribly surprising as it's the stage that takes the longest time out of all of those we have
MasterDuke and this is just for running the file dogbert11 was testing with? 12:34
timotimo oh no this is the core setting compilation
MasterDuke heh, yeah, that's going to take a while
timotimo i'll go afk for a bit again and see when it terminates 12:36
i bet it'll crash when it reaches ~15 gigs because that's how much ram i have and i'm storing the file on my /tm
on my /tmp
jnthn . 12:38
yoleaux 12:08Z <MasterDuke> jnthn: is this github.com/rakudo/rakudo/blame/nom...nc.pm#L201 a debugging leftover?
jnthn MasterDuke: Yes, d'oh
Geth rakudo/nom: 91cefc1a78 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/IO/Socket/Async.pm
Remove debugging leftover
 12:39
rakudo/nom: cf95ce81c4 | (Zoffix Znet)++ | src/core/Cool.pm
Slightly improve Cool.subst-mutate error

  ā€¦when called on non-writable invocants.
Use param name more suitable to the context where the error occurs.
  - Str.subst-mutate doesn't need similar treatment, as those methods
  are multies and we just get an X::Multi::NoMatch from them.		 12:42
MasterDuke oops, meant to say this here 12:54
when i just slurp the 50mb, 1million line file, i get 660620maxresident. when i remove the 27 lines with unicode in them, 487160maxresident 12:55
makes sense that it's bigger of course, but that's still a pretty large maxresident for a 50mb file 12:56
timotimo 3.9 gigs 12:58
it is, yeah 12:59
i'm still wondering if we should have an optimization for reading in large amounts of data where it constructs a strand where parts are represented as 8bit and other parts as 32bit
MasterDuke that would be nice 13:01
Geth roast: mryan++ created pull request #331:
Added tests to cover <ww> - within word		 13:03
timotimo of course if we use .IO.lines it should already store each line as the smallest thing it can, shouldn't it? 13:04
MasterDuke yeah, it would only really help when slurping or something like that 13:05
Geth roast: b0261d7eb8 | mryan++ (committed by Zoffix Znet) | S05-mass/rx.t
Added tests to cover <ww> - within word (#331)

Added tests to cover the predefined subrule <ww>. As explained in RT #293, word boundary, <wb> is well tested but not <ww> which has a seperate implementation in nqp.
These tests fill that void. Resolves: RT #293
timotimo gist.github.com/timo/7da2609bfd3a4...c12e891ffc - here's an analysis of just a small chunk of the file i'm writing 13:06
might be interesting to see if anything inside QRegex has changed in between those commits dogbert11 checked
MATCH has a few "$blah ne ''" that could probably be replaced with something faster 13:13
m: use nqp; say nqp::isnull_s("")
camelia 0
timotimo m: use nqp; say nqp::istrue_s("")
camelia ===SORRY!===
No registered operation handler for 'istrue_s'
timotimo we do have an istrue_s in moar, but we don't seem to map it in nqp at all 13:14
MasterDuke huh. is it used internally in moar anywhere? 13:15
timotimo probably
hm, not really 13:16
it could be used here, but it's not used anywhere as an op in moar or nqp 13:17
MasterDuke isfalse_s does `MVM_coerce_istrue_s(tc, GET_REG(cur_op, 2).s) ? 0 : 1`, wouldn't `!MVM_coerce_istrue_s(tc, GET_REG(cur_op, 2).s)` be faster?
timotimo i don't think the compiler would generate different code for those two
MasterDuke huh, isfalse_s is in nqp 13:18
timotimo only in the jvm part, though, no?
m: use nqp; say nqp::isfalse_s("")
camelia ===SORRY!===
No registered operation handler for 'isfalse_s'
timotimo j: use nqp; say nqp::isfalse_s("")
camelia Error while reading '/home/camelia/p6eval-token': No such file or directory at /home/camelia/rakudo-j-inst/bin/eval-client.pl line 10.
timotimo oh, well
MasterDuke src/vm/moar/NQP/Ops.nqp:123: push_op(@ins, 'isfalse_s', $not_reg, $val.result_reg); 13:19
istrue_s is only in jvm
timotimo haha
i don't really see why method !cursor_pass would call string equals 13:20
perhaps something implements "if $mystr" as comparison against '' 13:21
strange, i shall look at the speshlog
jdv79 MasterDuke: whatever works for you 13:27
timotimo huh, !cursor_pass isn't considered for speshing? 13:28
MasterDuke that seems...sub-optimal
jdv79: cool, i'll make that change 13:29
timotimo it says it got 783 hits in total 13:30
one of the callsite versions got 454 hits
MasterDuke i don't remember how it decides, some absolute value of hits needed? or percent of a version greater than some threshold? 13:31
timotimo well, worst case it would have made a certain specialization just based on the callsite shape 13:32
MasterDuke oh huh, diag(<something>) is used a bunch in roast tests
maybe i'll leave it as is then, since the real problem is the errors because i have IPv6 disabled 13:35
timotimo oh, btw, the "doesn't get speshed" thing was from a different workload 13:36
one with much less code to compile
MasterDuke ah 13:37
timotimo uh oh, my system is not happy right now 13:38
dogbert11 running out of memory?
timotimo barely
11 gigs out of 15 gig used
Konsole is getting unhappy 13:39
perhaps i put far too much output in it :S
ok, back to usual
dogbert11 btw, managed to get the syntax.t test discussed yesterday to SEGV 13:43
timotimo segfault? huh
dogbert11 yup, read all about it :) gist.github.com/dogbert17/d018b0f6...0f734d0dbc
timotimo it could be that getlexperinvtype caused the string comparison in cursor_pass when trying to look up $?CLASS 13:46
oh crap something's filling up my hard drive 13:48
oh!
dogbert11 uh oh
timotimo i don't actually have a tmpfs on /tmp
MasterDuke whoops 13:49
timotimo no wonder a bunch of programs crashed
including kwin and plasmashell
dogbert11 this syntax.t test is a bit of a mystery 13:53
if I run it in a loop, most of the time the results are: 2.03user 0.68system 0:01.25elapsed 216%CPU (0avgtext+0avgdata 155844maxresident)k 13:54
that is pretty consistent, but once in a while something strange happens and the results are much worse 13:55
like this : 35.11user 23.60system 0:59.61elapsed 98%CPU (0avgtext+0avgdata 1157060maxresident)k
timotimo mhm 13:56
getlexperinvtype doesn't really do a string comparison, though
dogbert11 and sometimes, as we know, the result is: Command terminated by signal 11
timotimo i've never had a segfault there 13:57
dogbert11 I must set MVM_SPESH_BLOCKING=1 for it to happen
timotimo ah 13:58
MasterDuke that moarvm backtrace is scary, all GC related 14:01
dogbert11: but doesn't happen when disabling jit and/or spesh?
dogbert11 MasterDuke: will try to disable spesh, don't have the jit since I'm on 32 bit 14:02
MasterDuke right 14:03
didn't you just upgrade your system? but the vm is 32bit?
dogbert11 yeah, it's the vm 14:06
I transferred it from my old machine
MasterDuke have you noticed that things inside the vm run any faster on the new machine? 14:07
dogbert11 disabling spesh seems to help, no crashes yet, but the strange slow down and eat lots of memory problem still crops up
MasterDuke maybe try running it with heaptrack and see what it says when you get a large memory run? 14:08
dogbert11 I'd say it's a bit faster in ST but the biggest gain is the MT thanks to additional cores
another tool I have never used :) 14:09
MasterDuke makes sense
dogbert11 the cores in my old system were good but there were too few of them :) 14:10
I convinced myself I deserved the upgrade after using it for ~7 years 14:11
MasterDuke pretty much my exact thinking 14:15
dogbert11 I saw that one run was slow so I attached gdb to it, all I can see is this:
7 Thread 0xb0ffeb40 (LWP 15107) "moar" 0xb7346a7a in gc_mark (tc=0xb22a47a0, st=0xaccbc90, data=0x92e21c40, worklist=0xa73e6f38) at src/6model/reprs/VMArray.c:76
2 Thread 0xaa5f6b40 (LWP 15112) "moar" 0xb732c9eb in MVM_gc_root_add_frame_registers_to_worklist (tc=tc@entry=0xb14852e8, worklist=worklist@entry=0xa365e698, frame=<optimized out>, frame@entry=0x93332c90)
at src/gc/roots.c:409
it will probably complete if I let it continue 14:16
MasterDuke timotimo: github.com/MoarVM/MoarVM/blob/mast...ps.c#L1707 looks like we always allocate the space for MVMGrapheme32 when joining strings. could we check if they're each MVMGrapheme(8|ASCII) and then allocate less if so? 14:18
timotimo yeah
does re_nfg try to make things smaller? 14:19
well, probably not
MasterDuke nope 14:20
timotimo since if you're combining stuff, it's likely you'll end up with nfg-related stuff
MasterDuke isn't there some function to convert 32bit to 8bit? 14:21
ah, turn_32bit_into_8bit_unchecked 14:22
but if you're combining all 8bit or ascii strings, would they ever not be concat stable? 14:25
timotimo there's \r and \n
where \r\n turns into a synthetic
MasterDuke but isn't there a way to special case that? 14:26
timotimo not sure 14:29
jnthn++ # bloggage 14:34
Geth rakudo/nom: 21f05e3f1e | (Nick Logan)++ (committed using GitHub Web editor) | src/core/Proc/Async.pm
Remove unused attributes
 15:08
ugexe moar/nqp need a bump for rakudo to go green on appveyor it looks like 15:11
we could change the appveyor badge to show green if only --gen-moar=master --gen-nqp=master passes 15:13
Geth roast: 2f9a131a61 | (Zoffix Znet)++ | S06-other/main-usage.t
Rewrite the file to be more concise

For easier reading		 15:16
Zoffix ^ (forgot to add: no functional changes) 15:17
timotimo i wrote a little spesh opt that turns eq_s and ne_s against a known empty string into an istrue_s or isfalse_s 15:30
it triggers a bunch of times while doing the core setting parse
so maybe that can reduce the amount of time spent inside MVM_string_equal
MasterDuke and stage parse now takes only 5s? 15:31
lizmat didn't know istrue_x was a thing
timotimo haha 15:33
lizmat: it's not available as nqp:: op it looks like
but only because a line is missing in the QASTOperationsMAST file
well, two lines :)
MasterDuke lizmat: btw, s is the only _* 15:34
lizmat ok, well, there's one occurrence in the setting in "get_next_substitution_result" 15:35
(of iseq_s(...,'')
timotimo but with that spesh opt it's the same if you write ne ""
MasterDuke istrue and isfalse are both used a bunch in the rakudo source, the only _* mention is: src/vm/moar/Perl6/Ops.nqp:301: nqp::push(@ops, MAST::Op.new( :op('istrue_s'), $tmp_reg, $exprres.result_reg ));
Geth rakudo: skids++ created pull request #1170:
Look for yada fullfillment in default parent type, too (RT#131676)		 15:36
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131676
timotimo i'm now doing a callgrind of core setting compilation to see if the amount of time spent in string equal goes down noticably
i mean, there's already a shortcut in the equals code for strings having the same amount of graphemes 15:37
MasterDuke lizmat: i see three uses of iseq_s(...,'') 15:38
src/core/Rakudo/Internals.pm:1000,1001 and src/core/Str.pm:2410:
Zoffix ZOFFLOP: t/spec/S17-supply/stable. 15:43
MasterDuke hm, optimizing MVM_string_join is kind of annoying, because Perl 6 strings are stands of MVMGrapheme32 by default 15:47
timotimo so it doesn't often see that it could do it? 15:49
MasterDuke well, there a comment about how we could just collect all the things as strands, but that's not implemented. that would probably help a bunch 15:51
timotimo maybe we can find more places where we create strings to use smaller storage strategies
MasterDuke otherwise you'd have to be using native strs to get a benefit from other optimization
lizmat timotimo: there are several places in the core where natives are *not* used because of vague issues 15:53
I seem to recall natives in roles not optimizing
timotimo i was refering exclusively to moarvm code with that
because the only influence HLL code can have on the internal storage is to flatten out strands 15:54
like we do for regex matching
travis-ci Rakudo build failed. Nick Logan 'Remove unused attributes' 15:55
travis-ci.org/rakudo/rakudo/builds/278964569 github.com/rakudo/rakudo/compare/c...f05e3f1e6e
buggable [travis build above] ā˜  All failures are due to: failed make test (1 failure). Across all jobs, only t/01-sanity/99-test-basic.t test file failed.
gfldex while trying to teach JSON::Fast to handle DateTime correctly I stepped on a bit of a problem
m: my $d = now.DateTime; my $d2 = DateTime.new($d.Str); say $d eqv $d2;
camelia False
gfldex m: my $d = DateTime.now; my $d2 = DateTime.new($d.Str); say $d eqv $d2;
camelia False
gfldex that only applies to DateTime objects that are created by using an Instant 15:56
timotimo m: my $d = DateTime.new; my $d2 = DateTime.new($d.Str); say $d; say $d2; say $d.perl; say $d2.perl
camelia Cannot call DateTime.new with no parameters
in block <unit> at <tmp> line 1
timotimo m: my $d = DateTime.now; my $d2 = DateTime.new($d.Str); say $d; say $d2; say $d.perl; say $d2.perl
camelia 2017-09-23T17:56:42.406978+02:00
2017-09-23T17:56:42.406978+02:00
DateTime.new(2017,9,23,17,56,42.4069781303406,:timezone(7200))
DateTime.new(2017,9,23,17,56,42.406978,:timezone(7200))
timotimo ah
it cuts off the accuracy 15:57
gfldex indeed
but the problem may reach deeper
it may very well be that we need ā‰… for DateTime and Instant 15:58
timotimo: I'm confident there will be a PR for JSON::Fast today that got a working solution. 15:59
timotimo cool :)
if you'd like i'll make you contributor
Geth rakudo/nom: 0b15f6728a | (Zoffix Znet)++ | src/core/Main.pm
Implement $*USAGE

  - Provides default USAGE message the program would generate
  - Available as dynvar $*USAGE inside MAIN and USAGE subs; USAGE sub
   can use it as a base to generate custom usage, for example.
  - Speculation describes $?USAGE, but we renamed[^1] it since at compile
   time we don't know if we'll ever need it
  - Die if user attempts to assign into it
  [1] irclog.perlgeek.de/perl6-dev/2017-...i_15206569		 16:01
roast: 04b03b1d40 | (Zoffix Znet)++ | S06-other/main-usage.t
Spec $*USAGE

Rakudo impl: github.com/rakudo/rakudo/commit/0b15f6728a		 16:02
specs: aec781246c | (Zoffix Znet)++ | 2 files
Add notes $?USAGE was renamed to $*USAGE

Rakudo impl: github.com/rakudo/rakudo/commit/0b15f6728a Spec: github.com/perl6/roast/commit/04b03b1d40 Docs: github.com/perl6/doc/commit/9849f0945f		 16:03
timotimo does another callgrind to compare 16:16
dangit, it'll take like 45 minutes or something >_< 16:17
14th place for MVM_string_equal (though it for some reason also has the 15th place) with my opt in place 16:18
and adding the two numbers up it arrives at 4th place 16:19
it's done! 16:52
there's almost no difference :\ 16:53
dogbert11 oh no
timotimo like 7 million fewer instructions 16:54
but MVM_string_equal in total is responsible for about 6000 million instructions
it's still a mystery why string comparison went up by so much 17:10
travis-ci Rakudo build passed. Zoffix Znet 'Implement $*USAGE 17:24
travis-ci.org/rakudo/rakudo/builds/278978602 github.com/rakudo/rakudo/compare/2...15f6728a4a
dogbert11 timotimo: I might be misinterpreting what kcachegrind tells me but a lot of calls seems to come from MVM_frame_find_lexical_by_name 17:34
timotimo oh? interesting. 17:37
i thought about that, too, but i didn't find many corresponding calls in the spesh 17:38
could be wrong of course
dogbert11 as could I :)
timotimo and i don't find the string equals in there. prehaps it's in the HASH_GET
it's almost 99% $?CLASS 17:40
dogbert11 HASH_GET sounds familiar
timotimo perhaps something broke the spesh opt that can specialize on $?CLASS cleverly
dogbert11 somthing called MVM_HASH_GET, is that the same?
gfldex m: say DateTime.now.posix, Date.today.posix; 17:42
camelia No such method 'posix' for invocant of type 'Date'
in block <unit> at <tmp> line 1
dogbert11 how do you figure out if that opt is broken? 17:44
cognominal jnthn++ # guts 18:38
yoleaux AlexDaniel: teach bisectable to bisect moar, you idiot. 18:49
AelxDnaiel :|
cognominal the rise of the bots ? 18:52
Zoffix ZofBot: I'll be spared, though, right? 20:14
ZofBot Zoffix, jnthn: while siegeing the golfed httpd I got "MoarVM oops: Return label is NULL!"

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!