Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-11-13

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 stmuk joined #moarvm
00:16 Ven_ joined #moarvm
00:18 FROGGS joined #moarvm
00:22 retupmoca joined #moarvm
00:50 FROGGS joined #moarvm
01:53 tokuhiro_ joined #moarvm
02:23 flussence joined #moarvm
02:38 psch joined #moarvm
02:45 hoelzro joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:20 colomon joined #moarvm
06:37 domidumont joined #moarvm
06:54 domidumont joined #moarvm
07:18 nwc10 good *, #moarvm
07:46 FROGGS joined #moarvm
07:54 brrt joined #moarvm
07:54 brrt \o #moarvm
07:54 nwc10 o/ brrt
08:00 brrt \o nwc10
08:01 * brrt is pondering writing a jit log parser in perl6
08:01 brrt which would be my first real perl6 program
08:30 JimmyZ brrt: Did you try lua's showing jit code through gdb? P
08:33 zakharyas joined #moarvm
08:43 brrt JimmyZ - you mean the luajit gdb integration
08:43 brrt didn't do that, now
08:43 brrt no
08:43 brrt shoud do that once
08:43 brrt would be nice
08:43 brrt but i'm bikeshedding enough as it is
08:44 brrt it's a nice-to-have
08:47 JimmyZ yeah.
09:34 kjs_ joined #moarvm
10:06 zakharyas joined #moarvm
10:06 jnthn morning o/
10:06 stmuk Lee on another channel has pointed me at
10:07 stmuk https://github.com/MoarVM/MoarVM/pull/287
10:07 brrt morning jnthn
10:09 jnthn stmuk: In theory, https://github.com/MoarVM/MoarVM/commit/b2c18a31e037bcc44362031a5b765bc4c8a103c1 got rid of that warning
10:10 jnthn stmuk: Does it still show up on latest?
10:10 stmuk I'll check
10:11 jnthn Thanks :)
10:11 nwc10 that was very off-topic for *that* channel. It's supposed to be about beer. Or was it buffy. I forget
10:12 stmuk jnthn: sorry those warnings are fixed .. although there are "warning: assigning to 'MVMuint8 *" in 4 files which I shall try and poke sue to fix
10:15 jnthn stmuk: Yes, those warnings want fixing (and don't show up on my regular compiler). Thanks.
10:16 jnthn The || vs && prec one drove me nuts.
10:18 stmuk I always found it ironic gcc had warnings compiling itself - a case of "do as I say not how I do"
10:25 dalek MoarVM: 902e1ba | (Francois Perrad)++ | src/io/ (2 files):
10:25 dalek MoarVM: remove unreachable code
10:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/902e1ba8b8
10:25 dalek MoarVM: 19757bd | jnthn++ | src/io/ (2 files):
10:25 dalek MoarVM: Merge pull request #270 from fperrad/lint_20150925_io
10:25 dalek MoarVM:
10:25 dalek MoarVM: remove unreachable code
10:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/19757bd7ed
10:35 dalek MoarVM: d4a20f0 | jnthn++ | src/strings/decode_stream.c:
10:35 dalek MoarVM: Re-use, rather than repeat, \r\n grapheme code.
10:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d4a20f0d02
10:39 dalek MoarVM: c2908ce | peschwa++ | src/ (3 files):
10:39 dalek MoarVM: Make MVMMultiCache container aware.
10:39 dalek MoarVM:
10:39 dalek MoarVM: This patch allows caching of Rakudo multi candidates that dispatch differently
10:39 dalek MoarVM: with identical types but different rwness.  I'm not completely sure that
10:39 dalek MoarVM: nothing has to be done for MVM_multi_cache_find_spesh, but I haven't come
10:39 dalek MoarVM: across any breakage without adding something there. Of course that doesn't
10:39 dalek MoarVM: necessarily show there isn't any.
10:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c2908ce6b4
10:40 dalek MoarVM: bdb61f2 | peschwa++ | src/6model/reprs/MVMMultiCache.c:
10:40 dalek MoarVM: Fix missing space after conjunction.
10:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bdb61f2827
10:44 dalek MoarVM: 8dbc50e | jnthn++ | src/ (2 files):
10:44 dalek MoarVM: Move constant, and explain it better.
10:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8dbc50e221
10:59 jnthn Odd, my seemingly innocent perf refactor of psch++'s multi cache causes explosions...
11:00 * jnthn gets out the debugger
11:02 jnthn ah, duh
11:02 nwc10 "insufficient coffee"?
11:04 jnthn Pretty much :)
11:10 dalek MoarVM: aa14aa0 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
11:10 dalek MoarVM: Simplify/optimize multi cache rwness bits.
11:10 dalek MoarVM:
11:10 dalek MoarVM: Move code into paths that already did various checks, and make use of
11:10 dalek MoarVM: a NativeRef always being writable to avoid the checks on that.
11:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/aa14aa09e5
11:21 jnthn Darn, fixing the spesh/multi cache thing will be a little tricky.
11:22 jnthn But really needs doing, not only 'cus it's wrong now, but because it affects our ability to inline things as simple as $i++
12:07 timotimo this is about all kinds of inlining with lexfers involved?
12:07 jnthn No
12:08 jnthn I mean $i++ on a simple Int
12:08 jnthn Not even natives involved
12:08 timotimo oh
12:08 timotimo fair enough
12:08 jnthn Because the multi cache now needs the "yes it's rw" mark set
12:08 nwc10 ilmari: lunch, er ASAN
12:08 timotimo OK, fair enough
12:09 * jnthn is building a patch at the moment
12:09 jnthn yay, it actually fixes my test caes
12:09 jnthn Not bad for first time
12:10 timotimo first time's the charm
12:10 jnthn Doesn't fix inlining of $i++ though
12:11 jnthn m-prof: my $i = 1; while $i++ < 1000000 { }
12:11 jnthn camelia: help
12:11 camelia jnthn: Usage: <(nqp-js|debug-cat|prof-m|p5-to-p6|rakudo-MOAR|pugs|star-m|nqp-parrot|std|nqp-moarvm|nqp-jvm|niecza|rakudo-moar|rakudo-jvm|star-j|nqp-q|rakudo|nrP|Pnr|nPr|p6|j|Prn|r-m|m|M|nqp-j|r|nr|nqp|rm|sj|p56|r-j|star|rn|n|r-jvm|rPn|rnP|sm|nqp-mvm|perl6|nqp-p|P|rj|nom|nqp-m)(?^::\s(?!OUTPUT))
12:11 camelia ..$perl6_program>
12:11 jnthn oh
12:11 jnthn prof-m: my $i = 1; while $i++ < 1000000 { }
12:11 camelia prof-m 273e89: OUTPUT«Writing profiler output to /tmp/mprof.html␤»
12:11 camelia .. Prof: http://p.p6c.org/1a1537f
12:11 timotimo can you only speshed, not jitted, eh?
12:11 jnthn OK, that's not a regression
12:11 timotimo and also not inlined
12:12 jnthn yeah, wonder why no jit
12:12 jnthn Going to spectest this patch, anyways
12:13 jnthn I think psch++ will be glad I didn't send him off for a spesh baptism of fire to write this one :)
12:13 jnthn timotimo: If you fancy some (probably easy) JIT work, you could fix the two new guard ops :)
12:13 timotimo ah
12:13 jnthn uh, s/fix/add JIT for/
12:13 timotimo perhaps the jit isn't happy about isrwcont?
12:13 jnthn Maybe that too
12:13 timotimo that's exactly it
12:13 timotimo (on my machine at least)
12:13 jnthn Oh, but with what I just did
12:13 jnthn We can spesh that away ;)
12:14 timotimo oh, neato
12:14 jnthn My patch adds a "we know it's an rw cont" fact flat
12:14 jnthn fag
12:14 jnthn flag
12:14 jnthn gah
12:14 timotimo do you think it'll ever have an isrwcont and not have that flag? in that case i'll add it to the jit anyway
12:14 jnthn Could happen
12:14 timotimo 'k
12:14 timotimo probably very easy to write anyway
12:15 jnthn Though in the patch I'll prolly push soon I assumed that we're unlikely to get polymorphism around rwness
12:15 timotimo that's fair
12:15 jnthn (Mostly 'cus it made the patch easier :))
12:16 jnthn (Though only a little)
12:16 * jnthn still likes the spesh code, having just come back to it for the first time in quite a while
12:17 jnthn I'm kinda looking forward to next year, when I can take my "chase down/fix language semantics issues" hat off for a bit and wear my optimization/robustness one. :)
12:18 timotimo this'll want me to write an iscont_rw function in containers.c and that'll want me to figure out how to read that bit from an object
12:18 jnthn Don't think you need a function
12:18 jnthn You do what iscont does
12:19 jnthn And then if it is, you look up the ->can_store function from the container spec
12:19 jnthn And just call that
12:19 timotimo ah, thought so
12:19 jnthn Guess it's easy enough to call things through function pointers in the JIT
12:20 timotimo yup
12:20 timotimo but i'll still write it as a C function
12:21 timotimo i don't think it's performance-critical enough to turn that into jit code to get rid of that single indirection
12:21 jnthn I guess not, if we can optimize it out
12:21 jnthn Please then make the interpreter also use that function
12:21 jnthn So we reduce the number of code paths doing the same thing
12:21 jnthn The C compiler will probably go and inline it for us
12:22 timotimo just making sure here, iscont_rw is about more than just nativeref?
12:22 jnthn Yes
12:22 timotimo good
12:23 timotimo if (contspec && contspec->can_store(cont)), right?
12:23 jnthn aye
12:23 jnthn uh, tc, cont
12:23 timotimo tc, yeah
12:23 timotimo pseudocode anyway :)
12:25 timotimo you know, i could have just looked at isrwcont in inter.pc
12:25 timotimo interp.c
12:25 timotimo it seems like i'm still a bit foggy from sleepyness?
12:26 dalek MoarVM: b86c7b9 | jnthn++ | / (6 files):
12:26 dalek MoarVM: Add new spesh guard ops for rw containers.
12:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b86c7b9946
12:26 dalek MoarVM: 480dc8c | jnthn++ | src/ (7 files):
12:26 dalek MoarVM: Add a spesh flag for "known rw container".
12:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/480dc8c126
12:26 dalek MoarVM: 0181385 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
12:26 dalek MoarVM: Use spesh rw cont flag when searching multi cache.
12:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0181385cc7
12:26 jnthn sleepyness will do that...
12:28 timotimo the meds i have make me feel a bit better, but i think they're purely symptomatic
12:31 timotimo um, after pulling your latest patches, do i have to rebuild nqp&rakudo? because that code from earlier gives me a segfault now
12:32 jnthn Yes
12:32 timotimo good
12:32 jnthn Turns out that the spesh routines in the perl6 dynops end up with the spesh op IDs compile in
12:32 timotimo oh!
12:33 timotimo yeah, that can happen
12:33 jnthn We should fix that, so there's an API to look up the spesh op IDs late bound
12:33 timotimo mhm
12:33 jnthn Otherwise we'll have a binary compat problem down the line
12:33 timotimo we could open a github issue about that and give it to someone new-ish
12:35 timotimo if you want me to, i'll write it
12:37 jnthn Go for it :)
12:38 timotimo hm, currently the isrwcont survives instead of turning into a guard
12:38 timotimo ah
12:38 timotimo there's a guardrwconc in the <unit> frame, though
12:38 * timotimo gets crackin'
12:39 jnthn If the fact is there, you can rely on it
12:39 jnthn As in, it should just go away, not turn into a guard
12:39 timotimo er, yeah
12:39 jnthn Much like deconts do
12:39 timotimo well, it's a deconted_concrete_rw flag, but the isrwcont is on the arg itself, not its decont
12:41 timotimo maybe that's why it doesn't trigger?
12:41 jnthn I only mean that we handle unrequired deconts by deleting them (well, replace with set), and that's what we'll want to do with isrwcont
12:41 dalek MoarVM: e0c7ae4 | timotimo++ | src/ (3 files):
12:41 dalek MoarVM: isrwcont can now be jit'd
12:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e0c7ae40f0
12:42 timotimo oh, so you mean there's just no code in place yet to optimize away the isrwcont
12:42 timotimo got'cha
12:42 jnthn Correct
12:42 jnthn We couldn't do anything for it before now
12:42 jnthn But with the flag I added I think we now can :)
12:42 jnthn Just turn it into an iconst iff we have that flag.
12:43 jnthn (If we don't have the flag, it's a "don't know" and we'll have to leave it as it is)
12:44 timotimo right, it'll become an const_i, that'll go into the assertparamcheck and the assertparamcheck will disappear
12:44 jnthn Right
12:44 jnthn And take the const_i with it
12:46 timotimo yeah
12:46 timotimo and all will be well
12:47 jnthn Yeah
12:47 jnthn Wonder what then keeps the ++ from inlining
12:48 timotimo there's a branch that adds a bunch of debugging spam
12:48 timotimo it's literally called something with "spam" in its name
12:48 timotimo debugspam_inlining
13:05 timotimo my assembly is a tiny bit shaky, so i'm hoping the spec tests will exercise this sufficiently
13:12 timotimo jnthn: i get "all tests successfull", but do you have a piece of code that'd explode if the guards were wrong?
13:14 timotimo i suppose i'll just push the patch and see if someone complains
13:15 dalek MoarVM: 4f5c97c | timotimo++ | src/jit/ (2 files):
13:15 dalek MoarVM: implement guardrwtype and guardrwconc in the jit
13:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4f5c97c15d
13:16 jnthn timotimo: Well, maybe that by-trait.t one would
13:16 timotimo t/spec/S06-multi/by-trait.t ................................... ok
13:16 timotimo :)
13:18 timotimo i've already had a little patch to spesh iscont and iscont_*, but it caused breakage :(
13:18 psch S06-multi/by-trait.t doesn't have any native rw specific tests currently though, if that could matter
13:19 jnthn psch: Yes, the native types behavior is the only thing currently keeping me from considering the RT resolved
13:19 jnthn psch: Why does the multi dispatcher throw X::Parameter::RW?
13:20 psch jnthn: because otherwise it would throw Multi::NoMatch
13:20 jnthn I don't think it should. I've just spent a while debugging the multi dispatcher to see why it was getting as far as dispatching
13:20 jnthn Thinking it was doing so
13:20 jnthn Yes, it should throw a Multi::NoMatch!
13:20 psch jnthn: then roast is wrong
13:20 psch m: ++"x"
13:20 camelia rakudo-moar f3e960: OUTPUT«Parameter '$a' expected a writable container, but got Str value␤  in block <unit> at /tmp/kDAMdHbsym:1␤␤»
13:20 jnthn Agree :)
13:20 timotimo the naming of "deconted_concrete_rw" bugs me; it sounds like "deconts to something that is rw", but it's really "a rw container that contains something concrete"
13:20 jnthn timotimo: Feel free to change it to something clearer :)
13:20 timotimo nah, i've got enough to do for starts :)
13:21 psch jnthn: that also means Parameter::RW only happens on non-multis, which makes it a bit over-specific, on a hunch
13:21 jnthn psch: Also fixing this will get us an error that shows the signature, which will be much clearer than the "where's that mysterious $a come from"
13:21 timotimo oh! yes!!
13:21 psch yeah, that i definitely agree with
13:22 jnthn psch: You could say the same about all signature binding exceptions that overlap with things multi dispatch cares for, though.
13:22 jnthn Anyway, lunch is ready here...so I'll go eat and bbi30 :)
13:23 timotimo only 30 minutes? you don't rush a good meal, jnthn :P
13:24 psch hm, i guess my Parameter::RW annoyance mostly hinges on "multis are different than sub", in the end
13:24 psch m: sub f(Int $) { }; f Str
13:24 camelia rakudo-moar f3e960: OUTPUT«===SORRY!=== Error while compiling /tmp/eC2y3GlKT0␤Calling f(Str) will never work with declared signature (Int)␤at /tmp/eC2y3GlKT0:1␤------> sub f(Int $) { }; ⏏f Str␤»
13:24 psch m: multi f(Int $) { }; multi f(Num $) { }; f Str
13:24 camelia rakudo-moar f3e960: OUTPUT«===SORRY!=== Error while compiling /tmp/p6hqKpfugY␤Calling f(Str) will never work with any of these multi signatures:␤    (Int) ␤    (Num)␤at /tmp/p6hqKpfugY:1␤------> multi f(Int $) { }; multi f(Num $) { }; ⏏f Str␤»
13:25 psch vOv
13:25 psch well, if roast is wrong about Parameter::RW on multis that's fine with me
13:28 nwc10 ilmari: ^^ hint from jnthn :-)
13:31 ilmari nwc10: I just finished my lunch :-P
13:31 nwc10 \o/
13:31 timotimo very good, isrwcont and assertparamcheck get thrown out
13:32 nwc10 good news: I've acchieved POETS
13:32 timotimo now it's getart, takedispatcher, p6oget_o, wval, wval, add_I, assign, return_o
13:32 nwc10 bad news: because I keep being in the office early.
13:32 timotimo getarg_o, not getart
13:33 vendethiel joined #moarvm
13:33 timotimo jnthn: it looks like postfix:<++> is inlined this time!
13:34 timotimo YES!
13:34 dalek MoarVM: 5f007a9 | timotimo++ | src/spesh/optimize.c:
13:34 dalek MoarVM: we can spesh isrwcont into a const now.
13:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5f007a9dba
13:37 timotimo i'm doing a before/after timing of that simple benchmark now
13:38 timotimo In total, 423 call frames were entered and exited by the profiled code. Inlining eliminated the need to create 1999586 call frames (that's 99.98%).
13:39 lizmat timotimo: that's for natives ?
13:39 timotimo no
13:40 lizmat ah, too bad  :-)
13:40 timotimo oh wow
13:40 lizmat but would it make ++ on natives faster nonetheless ?
13:40 timotimo 11.98user 0.02system 0:12.00elapsed 100%CPU (0avgtext+0avgdata 75384maxresident)k
13:40 timotimo 36.80user 0.06system 0:36.85elapsed 100%CPU (0avgtext+0avgdata 75664maxresident)k
13:40 lizmat 3x faster, it seems ?
13:40 timotimo just about
13:41 timotimo okay, here's timings for the native int case
13:42 timotimo 43.76user 0.05system 0:43.79elapsed 100%CPU (0avgtext+0avgdata 75712maxresident)k
13:42 timotimo ^- old-ish moar
13:46 timotimo 43.79user 0.07system 0:43.84elapsed 100%CPU (0avgtext+0avgdata 75672maxresident)k
13:46 timotimo ^- latest moar
13:48 timotimo yeah, still doesn't inline postfix:<++> there
13:48 timotimo it allocates ALL the IntLexRefs, too
13:50 timotimo huh, the code for postfix:<++> looks kind of ugly inside of spesh
13:51 timotimo it uses lexicals for that stuff, rather than registers
13:51 timotimo so the code is bindlex $a to hold the first argument
13:51 timotimo bindlex 0 to $b to initialize it
13:51 timotimo take dispatcher
13:51 timotimo getlex $a
13:52 timotimo decont an int from $a
13:52 timotimo bind the value of that into $b
13:52 timotimo getlex $a (again)
13:52 timotimo getlex $b (why?! whhhyyyyy)
13:52 timotimo load a 1
13:52 timotimo add that 1 to the $b we just got
13:52 timotimo assign the result into $a
13:53 timotimo get $b
13:53 timotimo return $b
13:54 timotimo it also has 4 deopt points, one before each getlex
13:56 timotimo using ++$i instead of $i++ with a native $i gives a crazy speed-up.
13:56 timotimo lizmat: ^
13:56 * lizmat will keep that in mind
13:56 timotimo ah :)
13:56 timotimo bon appetit on your breakfast
13:57 JimmyZ getlex is the most thing that can't be inlined, iirc
13:57 zakharyas joined #moarvm
13:57 JimmyZ that's why lex=> local branch want to be merged?
13:58 timotimo yeah, we really want lex=>local
13:58 timotimo interesting. ++$i actually doesn't inline prefix:<++> either
13:59 timotimo i was wrong about the speedup, too
13:59 timotimo there is actually no speedup at all
14:02 * jnthn back
14:03 timotimo urgh, our codegen ...
14:03 timotimo getlex       r2(1), lex(idx=0,outers=0,$a)
14:03 timotimo getlex       r3(1), lex(idx=0,outers=0,$a)
14:04 jnthn We need to be careful when optimizing such things
14:04 jnthn (For memory model reasons)
14:04 timotimo r2 gets used to assign the result of add_i-ing into, r3 gets used as the source for adding 1 to
14:04 timotimo the only thing between bindlex and getlex for $a is takedispatcher
14:05 timotimo but according to the profile, the unit costs 80.8% exclusive time
14:06 timotimo how the hell does it spend all that time? getlexref_i perhaps??
14:06 jnthn For the native case?
14:06 jnthn Probably. getlexref_i isn't that cheap
14:06 timotimo aye, and prefix:<++>
14:06 timotimo ah?
14:07 timotimo well, then that'd be a problem
14:07 jnthn Not really, given the assumption is that at some point spesh'll rip a bunch of them out.
14:07 timotimo hm. fair enough.
14:08 jnthn Though the design is such that we can optimize their taking too
14:08 Ven joined #moarvm
14:09 psch m: multi f(Int $x) { "Int" }; multi f(Int $x is rw) { "rwInt" }; multi f(int $x is rw) { "rwint" }; say f 5 # this seems to want another moar rev bump
14:09 camelia rakudo-moar cc1ba3: OUTPUT«rwint␤»
14:09 psch hrm, maybe it wants more, actually
14:10 psch 'cause latest moar does the same locally.  otoh, with --gen-moar i get a bunch of failures in by-trait.t
14:10 jnthn ?
14:10 jnthn I bumped NQP_REVISION/MOAR_REVISION?
14:11 psch jnthn: with --gen-moar i was 12 commits behind HEAD on moar
14:11 jnthn ah
14:11 jnthn I'm looking into the native rw stuff a bit at the moment
14:11 psch oh, but moar HEAD SEGVs again in by-trait.t ..?
14:11 timotimo hum. with my inlining debugspam i get output for unit trying to inline infix:«<»
14:11 timotimo but nothing for prefix:<++>
14:11 timotimo that's weird.
14:13 jnthn psch: Not for me
14:14 jnthn psch: Did you rebuild your Rakudo too?
14:14 psch yeah, i'm pretty sure i did
14:14 psch i'll git clean
14:18 timotimo OK, the attempt to get prefix:<++> fails after looking for the multiple dispatch cache
14:18 psch welp, must've messed something up somewhere along the way.  Configure.pl with --gen-{moar,nqp} works
14:18 timotimo as in, MVM_multi_cache_find_spesh returns 0
14:19 timotimo psch: not pointing a finger at you :P
14:20 psch timotimo: uh, i was talking about the SEGV i got... :)
14:20 psch as in, "messed up [building rakudo] somewhere"
14:20 timotimo no, i mean ... because cache_find_spesh
14:20 psch oh
14:20 psch yeah i didn't touch that :P
14:20 timotimo :)
14:20 jnthn timotimo: Odd, the patches I did shoulda been sufficient for us to find it
14:21 timotimo shall i put debugspam into that function?
14:21 psch running spectest against "no Parameter::RW from find_best_dispatchee", which also has some simplification of the rwness checking...
14:22 psch increment.t i already know needs adjusting
14:23 jnthn psch: Gah, we're both working on the same code then :/
14:23 * jnthn also just did that
14:23 jnthn psch: Go for updating the tests, anyway
14:29 timotimo jnthn: the reason why we bail for (what i assume must be) prefix:<++> is that arg 0 doesn't have the "known_type" flag set
14:29 jnthn o.O
14:29 jnthn Odd
14:30 jnthn timotimo: Wait, native or?
14:30 timotimo gimme a bit
14:30 timotimo yeah, that's native
14:30 jnthn yeah, we don't understand native refs enough in spesh yet
14:30 timotimo ah, it's that easy?
14:30 jnthn Yeah
14:30 psch jnthn: i've demoted $rwness_mismatch to an int, 'cause that's enough there
14:30 jnthn psch: OK, cool
14:31 timotimo wouldn't we just have to put an entry into facts.c to create_facts for getlexref_*?
14:31 psch not sure how much of an impact that has, but it probably adds up eventually...
14:34 jnthn aye :)
14:34 jnthn timotimo: I don't know. The truth is I don't want to have to think about it.
14:34 jnthn timotimo: I want to ignore it until next year.
14:34 jnthn I've too much on my plate.
14:35 timotimo understood
14:36 jnthn However we do it, we have to work out how we'll eliminate them post-inline
14:36 timotimo indeed
14:37 psch huh
14:38 psch sort_dispatchees confuses me
14:38 psch unless isnull { sort }
14:38 psch so if we have sorted candidates, sort them again..?
14:39 psch but apparently that's where the candidate order confusion with Range.new came from anyway, so it's probably fine as-is...
14:40 jnthn huh, it's if nqp::isnull(@candidates) {
14:40 jnthn oh, sort_dispatchees
14:40 psch m: *..42i
14:40 camelia rakudo-moar 041875: OUTPUT«WARNINGS:␤Useless use of ".." in expression "*..42i" in sink context (line 1)␤Complex objects are not valid endpoints for Ranges␤  in block <unit> at /tmp/PJ7c3XmOgQ:1␤␤»
14:40 psch yeah, i had changed sort_dispatchees to if isnull, but if i do that Range.new doesn't throw that anymore
14:40 psch because the Complex candidates moves out of the tie-group that has the Whatever candidate
14:41 psch sort_dispatchees is only called in World, from Actions.comp_unit
14:41 psch well, no idea... "don't touch it, it works!" vOv
14:42 jnthn ;)
14:42 jnthn It's possible there actually is a problem in Range also and this bug hides it
14:43 psch https://gist.github.com/peschwa/c17cb7ebb9692f5783d5 is the candidate ordering i get when i change sort_dispatchees to if isnull
14:43 psch i don't readily see why the Complex candidate would move out of the 2nd group...
14:44 psch i assume Match:D is in the 3rd group because of defcon, and the other two are there because no nominal
14:45 psch well, except compunit stuff and we don't resort correctly...
14:47 psch m: multi f() { }; multi f($) { }; my $dispordr = nqp::getattr(nqp::decont(&f), Routine, '$!dispatch_order'); say $dispordr.HOW.name($dispordr)
14:47 camelia rakudo-moar 041875: OUTPUT«VMNull␤»
14:47 psch that's because we don't actually sort_dispatchees_internal on a proto that hasn't been invoked yet when we sort_dispatchees
14:47 timotimo jnthn: the cache_find_spesh is expecting a container (which it has inspected the lexref type to be) to also have decont_concrete and decont_typeobj flags set; i should probably set the exact same flags that guard deconted_concrete_rw thing has?
14:50 tokuhiro_ joined #moarvm
14:51 timotimo it's kind of weird to say that a lexref_i would decont to something concrete
14:51 timotimo and to something which we know the type of
14:52 timotimo because what do i set the type to %)
15:01 timotimo it'd feel righter if the cache find could recognize native containers
15:48 nwc10 this is very strange. If I build Moar with ASAN, the setting build SEGVs
15:48 nwc10 if I use the same gcc, but build debugging and do the setting under valgrind, no SEGV
15:49 nwc10 (there is at least 1 unit byte passed to write() - so again, I assume that our MAST generator is skipping a byte or two for alignment and it's not initialised ever)
15:49 jnthn nwc10: SEGVs giving a nice ASAN hint of what went wrong?
15:49 nwc10 no, a SEGV that looks like a NULL pointer dereference
15:50 jnthn ah
15:50 Ven joined #moarvm
16:02 hoelzro o/ #moarvm
16:02 nwc10 \o hoelzro
16:02 nwc10 getting anywhere useful with ASAN?
16:02 hoelzro o/ nwc10
16:03 hoelzro yes! I managed to produce a bunch of failures with my branch last night =)
16:05 nwc10 er, "yay", I think
16:06 hoelzro heh
16:06 hoelzro well, it's progress
16:08 kjs_ joined #moarvm
16:12 Ven joined #moarvm
16:22 timotimo hm, i wonder if findnotcclass and friends need to be updated for the new \r\n stuff?
16:24 jnthn Not afaik
16:25 jnthn They've long dealt with synthetics
16:25 jnthn The only change wsa that \r\n became a synthetic
16:26 timotimo mhm
16:26 timotimo because json::fast got confused - i'll have to write a proper test case
16:28 jnthn Well, does it use nqp::ord?
16:30 timotimo argh
16:30 timotimo yes, it does
16:30 timotimo i thought i had implemented nom-ws as findnotcclass
16:30 jnthn Yeah, avoid nqp::ord
16:30 timotimo well, nqp::ordat in this case
16:30 jnthn Or more to the point
16:31 jnthn Avoid it if you are expecting to talk about chars :)
16:33 timotimo https://github.com/timo/json_fast/blob/master/lib/JSON/Fast.pm#L50-L59 - what would this look like in our shiny grapheme-clean world?
16:35 jnthn timotimo: hm, not sure why that bit would be an issue
16:36 timotimo hm, ok, could even be that that's not the problem
16:36 timotimo the symptom is "cannot parse an object starting in
16:36 timotimo "
16:36 timotimo with a newline there
16:41 timotimo so the thing that goes there gets grabbed with an nqp::substr($text, $pos, 1) and nqp::ordat($text, $pos) is known to not be 32, 10, 13 or 9
16:41 timotimo so i shall output a bit more stuff to debug
16:42 lizmat nqp::ordat is suspect, maybe, in the current NFG world?
16:42 lizmat it returns the codepoint of the base char, no?
16:42 lizmat so that would be 13 for both \r and \r\n
16:43 jnthn Aye
16:43 timotimo that should be fine
16:43 jnthn Though I don't see anything immediately in the code that would get bitten by it
16:43 timotimo and then substr should give me the synthetic of the next thing
16:48 timotimo buildy buildy buildy a new rakudo
16:50 pyrimidine joined #moarvm
16:51 Ven joined #moarvm
16:54 timotimo i can't reproduce that bug locally, grml
17:11 jnthn r: sub s_s(*%n)  { %n>>.say }; s_s(|{:assoc<list>},:assoc<left>);
17:11 camelia rakudo-moar 019a7f: OUTPUT«list␤»
17:11 camelia ..rakudo-jvm f0c6a0: OUTPUT«left␤»
17:12 timotimo argh! :)
17:14 jnthn Turns out one of the xmas RTs that was reported as a nextwith bug boils down to that
17:14 jnthn So, 2 become 1
17:14 Ven joined #moarvm
17:17 nwc10 will Christmas be before or after valentine's day? :-(
17:19 jnthn 6.v is quite a long way off :P
17:19 jnthn We're down to 47 xmas RTs by now
17:21 jnthn And 42 days until Dec 25th :)
17:21 nwc10 6*9
17:21 nwc10 and I think it *is* 54 days until Jan 6th
17:21 nwc10 but my brain is tired
17:22 hoelzro is there a tag for xmas?
17:23 jnthn Ther's a meta-ticket
17:23 jnthn https://rt.perl.org/Ticket/Display.html?id=123766
17:25 hoelzro thanks jnthn
17:50 colomon joined #moarvm
17:54 tokuhiro_ joined #moarvm
17:57 kjs_ joined #moarvm
18:48 kjs_ joined #moarvm
19:41 zakharyas joined #moarvm
20:17 FROGGS joined #moarvm
20:21 nwc10 timotimo: there's something very strange about commit 4f5c97c15d03f9 - implement guardrwtype and guardrwconc in the jit
20:21 nwc10 gcc 4.9 ASAN doesn't like it
20:22 nwc10 but gcc 4.9 without ASAN is OK, even running under valgrind
20:22 nwc10 specifically, with ASAN, the setting build will SEGV (just a NULL pointer dereference) unless I comment out the MVM_OP_sp_guardrwtype stuff
20:22 nwc10 but tests will still fail due to the MVM_OP_sp_guardrwconc stuff
20:23 nwc10 if I set MVM_JIT_DISABLE all is happy
20:23 nwc10 so I have no idea why the assembler stuff in the JIT messes with ASAN annotated code
20:23 nwc10 but valgrind doesn't spot any problems
20:40 timotimo nwc10: uh oh, let me have a look
20:42 timotimo oh, hm, asan only does malloc and free?
20:43 hoelzro timotimo: I take it you need it for calloc/realloc?
20:43 timotimo whereas valgrind does every single allocation?
20:43 timotimo huh?
20:43 timotimo no, i'm just wondering why my JIT stuff explodes
20:43 hoelzro timotimo: I was wondering what else you would need it for
20:43 timotimo perhaps invoking the magical brrt would help?
20:43 hoelzro nevermind me
20:43 timotimo another possibility would be to sanitize data access
20:45 timotimo nwc10: well, one thing that it does is call functions, so maybe there's something wrong with the way it does that?
20:47 nwc10 I really don't know.
20:47 timotimo can you give me some output to look at?
20:47 nwc10 I have to rebuild
20:47 nwc10 and it's a stack tracek mostly with ??
20:47 timotimo sorry; in that case i can rebuild, too
20:47 timotimo ah, of course. because jit :(
20:48 timotimo so, brrt, is my patch to introduce the new guard functions wrong? i didn't make it carefully enough i suspect
20:52 zakharyas joined #moarvm
20:54 timotimo oh, nwc10, you don't happen to have stumbled over the problem with asan where it'll give a nonzero exit code if there were any leaks at all, eh?
20:54 timotimo that seems to be new
20:54 nwc10 no, not met that
21:16 tokuhiro_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary