Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-18

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

All times shown according to UTC.

Time Nick Message
00:02 hoelzro jnthn: is there anything special I have to do to be able to remove it? when I try to build rakudo after removing it, I get a segfault =/
01:27 hoelzro so I removed linenoise from MoarVM, but now when I try to use Linenoise.pm (which I just created), linenoise's read() returns EAGAIN; is there anything Moar may be doing that would be interfering with standard iput?
01:27 hoelzro *input
01:52 dalek MoarVM/no-moar-linenoise: e30ab31 | hoelzro++ | / (13 files):
01:52 dalek MoarVM/no-moar-linenoise: Remove linenoise/readline
01:52 dalek MoarVM/no-moar-linenoise:
01:52 dalek MoarVM/no-moar-linenoise: Now that NativeCall is included with Rakudo, instead of having
01:52 dalek MoarVM/no-moar-linenoise: linenoise/readline functionality be bundled in as a VM-level op,
01:52 dalek MoarVM/no-moar-linenoise: let's create a NativeCall-based module for this functionality
01:52 dalek MoarVM/no-moar-linenoise: review: https://github.com/MoarVM/MoarVM/commit/e30ab31487
02:10 zakharyas joined #moarvm
02:17 hoelzro I'm guessing standard input is made non-blocking by MoarVM?
02:17 hoelzro that would explain what I'm seeing with linenoise
04:40 vendethiel joined #moarvm
05:21 vendethiel joined #moarvm
06:26 Peter_R joined #moarvm
06:32 pyrimidine joined #moarvm
07:28 zakharyas joined #moarvm
07:53 FROGGS joined #moarvm
07:56 Ven joined #moarvm
08:18 FROGGS joined #moarvm
08:50 FROGGS joined #moarvm
09:20 lizmat joined #moarvm
09:24 kjs_ joined #moarvm
09:25 Ven joined #moarvm
10:30 vendethiel joined #moarvm
10:34 Peter_R joined #moarvm
11:19 donaldh joined #moarvm
11:30 Ven joined #moarvm
11:38 Ven joined #moarvm
12:15 zakharyas joined #moarvm
12:39 hoelzro does MoarVM set STDIN to non-blocking by default?
12:44 nwc10 hoelzro: I fear that only jnthn really knows that, and he's $dayjob teaching on site
12:46 hoelzro I figured as much
12:48 FROGGS hoelzro: we set it to blocking by default in MVM_file_get_stdstream
12:48 hoelzro I see
12:48 Ven_ joined #moarvm
12:49 hoelzro I'm just thinking about how that will work when using NativeCall with libraries that expect stdin to be in blocking mode
12:52 nwc10 presumably they would break in the same way as anyone else calling them from code using an event loop
12:53 nwc10 that's sort of "how do other VMs/thingies cope with this?"
12:54 hoelzro nwc10: I'm not sure, but I'm thinking that Node.JS may be the only other environment that does this
12:54 hoelzro it's just surprising is all
12:55 hoelzro took me a bit of head scratching before I figured out why linenoise was constantly returning 0 length strings =)
12:55 FROGGS :o)
12:56 Ven joined #moarvm
13:03 Ven joined #moarvm
13:07 timotimo i'll continue work on devirtualizing repr ops now :)
13:10 Ven timotimo++
13:27 brrt joined #moarvm
13:27 brrt \o
13:28 brrt (the Bart sign, i'm flattered :-D)
13:29 timotimo :D
13:29 timotimo wait 'til i show you your new Bart Mobile
13:30 rurban joined #moarvm
13:32 brrt but yeah, timotimo++ for devirtualizing repr ops
13:32 brrt that's awesome work
13:33 timotimo :)
13:33 timotimo thank you
13:35 timotimo so brrt
13:36 timotimo should all _n related ops have their own piece of emit code?
13:36 brrt :-)
13:36 brrt what are the n related ops?
13:36 timotimo because of VAL_F and RV_F?
13:36 brrt oh
13:37 nwc10 I can't answer that directly, but there do seem to have been a series of easy to make, hard to spot systematic errors with floating point calling conventions
13:37 timotimo because we had that differently a whole bunch of time
13:37 brrt ehm.. well, yeah, unless you use checks afterwards to modify them, or conditionals like (op == foo_n ? RV_N : RV_I)
13:37 timotimo fair enough
13:37 timotimo but it'll always be needed, eh?
13:37 brrt but yes, that's true
13:37 nwc10 so anything that makes it harder to screw up, without making it harder to do thing generally, is a good idea
13:38 brrt floating points are basically always passed either on stack or in FPR, never in GPR
13:38 timotimo so much cleanup to do ...
13:38 brrt (on x86 and x86-64)
13:38 brrt the only thing that is really ambiguous as far as i know is passing structs
13:38 brrt and returning them
13:56 timotimo this damned huge switch statement ... so hard to have a good overview
13:58 brrt very true
13:59 brrt you can.... i'm not against making large tables
13:59 brrt in a header file for example
13:59 brrt and read from there
14:00 timotimo a header table?
14:28 dalek MoarVM/jit_devirtualize_reprops: e04e158 | timotimo++ | src/jit/graph.c:
14:28 dalek MoarVM/jit_devirtualize_reprops: shuffle all ops around, make sure we have all repr ops
14:28 dalek MoarVM/jit_devirtualize_reprops:
14:28 dalek MoarVM/jit_devirtualize_reprops: and only repr ops. at least in the consume_reprop function.
14:28 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/e04e1581e7
14:30 nwc10 timotimo: that commit isn't complete (or otherwise not working)
14:30 nwc10 src/jit/graph.c:808:65: error: ‘MVM_JIT_RV_STR’ undeclared (first use in this function)
14:30 brrt strs and objs are pointers
14:31 brrt so you should use MVM_JIT_RV_PTR (iirc)
14:34 brrt the rationale for using a ptr return type is that they will have different sizes per arch unlike the integer types which are defined as 64 bits
14:37 timotimo nwc10: i just noticed, too, thanks :)
14:37 timotimo i'll have a fixup commit coming soon
14:39 dalek MoarVM/jit_devirtualize_reprops: 878b0b1 | timotimo++ | src/jit/graph.c:
14:39 dalek MoarVM/jit_devirtualize_reprops: RV_STR doesn't exist ...
14:39 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/878b0b1839
14:39 dalek MoarVM/jit_devirtualize_reprops: 588810e | timotimo++ | src/jit/graph.c:
14:39 dalek MoarVM/jit_devirtualize_reprops: devirtualize bindkey and bindpos ops
14:39 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/588810e290
14:41 brrt oh, timotimo, btw, if you want to use a type definition in dynasm you have to enter a .type declaration
14:42 timotimo i don't understand why, but i understand that i'll have to do it from now on :)
14:42 timotimo which op to devirtualize next?
14:47 timotimo damn, i'm having trouble deciding
14:49 dalek MoarVM/jit_devirtualize_reprops: 487eb38 | timotimo++ | src/jit/graph.c:
14:49 dalek MoarVM/jit_devirtualize_reprops: since _o and _s can be handled the same way, we do that.
14:49 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/487eb384fb
14:49 brrt it's so that dynasm can recognise your reference as a type declaration
14:49 brrt rather than a variable
14:50 brrt dynasm doesn't parse C :-)
14:58 timotimo oh, i see
15:00 timotimo srsly, what op do i do next?
15:02 brrt hint; add a MVM_jit_log(tc, "emit repr op %s", op->name), and then count the number of these lines
15:06 timotimo my code is borked, though
15:08 dalek MoarVM/jit_devirtualize_reprops: f08bfad | timotimo++ | src/jit/graph.c:
15:08 dalek MoarVM/jit_devirtualize_reprops: actually hook up bindkey/pos ops, now this is broken :(
15:08 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/f08bfada12
15:09 FROGGS joined #moarvm
15:14 dalek MoarVM/jit_devirtualize_reprops: ff82dee | timotimo++ | src/jit/graph.c:
15:14 dalek MoarVM/jit_devirtualize_reprops: more wrongness fixes
15:14 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/ff82deeaba
15:16 timotimo why is it segfaulting now :(
15:17 brrt lets see
15:20 timotimo i'll go grocery shopping in the mean time
15:20 timotimo thanks for looking! :)
15:37 nwc10 timotimo: valgrind won't say more than this:
15:37 nwc10 ==21675== Invalid read of size 8
15:37 nwc10 ==21675==    at 0x4F656A3: MVM_interp_run (interp.c:2763)
15:37 nwc10 ==21675==    by 0x503A320: MVM_vm_run_file (moar.c:210)
15:37 nwc10 ==21675==    by 0x401250: main (main.c:189)
15:37 nwc10 so straight out NULL pointer dereference. No prior undefined behaviour
15:45 timotimo oh wait
15:46 timotimo it seems like i've been taking the value of the register
15:52 dalek MoarVM/jit_devirtualize_reprops: bcb2317 | timotimo++ | src/jit/graph.c:
15:52 dalek MoarVM/jit_devirtualize_reprops: fix thinko about register addr vs value
15:52 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/bcb231725f
15:55 timotimo should i wait until post release to merge jit_devirtualize_reprops into master?
16:01 timotimo brrt: how do you feel about allowing %d or something like that in log filenames/env vars that'd be filled in with the pid?
16:03 FROGGS timotimo: yes, please wait
16:03 brrt oh, i was just about to point you to the reg_addr thinko :-)
16:04 timotimo thanks :)
16:04 brrt i'm ok with that, or any other filename
16:04 brrt i had imagined the jit dump files were called MVMJitCode-$filename.bin
16:05 brrt but that was not the case yet
16:05 timotimo they do have the function name in them, though
16:06 brrt by the way, bindpos always passed the register directly, never the floating-point-containing-the-register
16:06 brrt it's an approximation. it is quite difficult to correlate an mvmframe to a filename or function
16:06 timotimo yeah
16:07 timotimo oh, so the _F is still wrong?
16:07 brrt yes
16:07 brrt you don't need it in this case
16:08 timotimo 1689 emit repr op elems
16:08 timotimo 291 emit repr op getattr_s
16:08 timotimo these are top 1 and 2
16:08 timotimo for compiling the setting
16:08 brrt when in doubt check src/core/interp.c ;-)
16:08 timotimo 4041 repr op push_i couldn't be devirtualized: type unknown
16:08 timotimo 1827 repr op atkey_o couldn't be devirtualized: type unknown
16:08 timotimo 941 repr op getattr_i couldn't be devirtualized: type unknown
16:09 timotimo these are interesting; though getattr with a known type will often be turned into a sp_p6o... op earlier on
16:17 brrt i'm going to have dinner
16:17 brrt see you :-)
16:21 dalek MoarVM/jit_devirtualize_reprops: 4b38c6c | brrt++ | src/jit/graph.c:
16:21 dalek MoarVM/jit_devirtualize_reprops: bindpos and bindkey take an MVMRegister argument
16:21 dalek MoarVM/jit_devirtualize_reprops:
16:21 dalek MoarVM/jit_devirtualize_reprops: Thus these are always passed as a regular value, never as a float.
16:21 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/4b38c6c851
16:31 timotimo 2114 emitted an atpos_* or atkey_* via jgb_consume_reprop
16:31 timotimo 1689 emitted a elems via jgb_consume_reprop
16:31 timotimo 201 emitted a bindpos_* or bindkey_* via jgb_consume_reprop
16:31 dalek MoarVM/jit_devirtualize_reprops: 9d61133 | timotimo++ | src/jit/graph.c:
16:31 dalek MoarVM/jit_devirtualize_reprops: implement MVM_op_elems for devirtualization
16:31 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/9d61133f31
16:44 timotimo seems to give no measurable difference on my int @a; my int $i; while $i < 10000000 { @a[$i] = 1; $i = $i + 1 }
16:48 timotimo hm
16:48 timotimo maybe it does
16:48 timotimo it's quite a noisy "benchmark"
16:49 timotimo ghhhhhhhhhhhhhhhrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrm
16:49 timotimo (that was cat)
16:53 timotimo for that benchmark, we have a few ops we could devirtualize (if they were implemented):
16:53 timotimo 44 emit repr op getattr_o
16:53 timotimo 22 emit repr op push_o
16:53 timotimo the rest is <10
16:54 timotimo (however, sadly that doesn't show usage distribution)
16:55 timotimo well, the frame that the code spends ~100% of time in already has all potential ops devirtualized
16:55 timotimo so that's something
16:56 timotimo and now i'll take the rest of the evening off (but not most of the night)
16:57 timotimo zpämmmmbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbnmmmmmmmmmmmmmmmmmmmmmmmmm000000000000000000000000000000
16:58 * jnthn wonders if the cat will take the evening off too :P
16:58 timotimo (also, i let the cat roam free all over my laptop keyboard)
16:58 timotimo he looks pretty pleased with himself, that cat
16:59 timotimo ~o/
16:59 timotimo (hair blowing in the wind)
17:03 donaldh joined #moarvm
17:10 FROGGS joined #moarvm
17:14 kjs_ joined #moarvm
18:39 kjs_ joined #moarvm
18:52 vendethiel joined #moarvm
19:01 timotimo can someone perhaps run benchmarks with and without that branch? maybe not the whole p6bench suite
19:01 * nwc10 can't, but ASAN didn't barf on it
19:53 mj41 joined #moarvm
20:34 colomon joined #moarvm
21:00 nwc10 jnthn: if you want MOAR news, I think it's reasonable to suggest that "we're building on big endian again (tested on PPC32 and PPC64)"
21:04 dalek MoarVM: 194de10 | jnthn++ | docs/ChangeLog:
21:04 dalek MoarVM: ChangeLog for 2015.03.
21:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/194de10315
21:04 jnthn nwc10: Yes, that's worth a "headline" mention I guess :)
21:08 dalek MoarVM: 7623778 | jnthn++ | VERSION:
21:08 dalek MoarVM: Bump VERSION.
21:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7623778912
21:08 dalek MoarVM: 327fc12 | jnthn++ | ports/macports/Portfile:
21:08 dalek MoarVM: Bump version in Portfile.
21:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/327fc129c6
21:14 dalek MoarVM/cpp2: 75e5909 | FROGGS++ | Configure.pl:
21:14 dalek MoarVM/cpp2: use CPPFLAGS if set, baby-gnu++
21:14 dalek MoarVM/cpp2: review: https://github.com/MoarVM/MoarVM/commit/75e5909cce
21:14 dalek MoarVM/cpp2: 309561c | (Daniel Dehennin)++ | Configure.pl:
21:14 dalek MoarVM/cpp2: Use CPPFLAGS is @cflags instead of @ldflags
21:14 dalek joined #moarvm
21:15 dalek joined #moarvm
21:20 kjs_ joined #moarvm
21:47 nebuchadnezzar arf, just see my typo :-/
21:49 FROGGS :o)
21:49 colomon joined #moarvm
21:51 japhb OOC, does bumping version in the Portfile get picked up automatically, or does someone end up having to ping the macports team?
21:54 jnthn http://www.moarvm.org/releases/MoarVM-2015.03.tar.gz
21:55 jnthn japhb: According to the release guide, I now have to make [Coke]++ ping the macports team.
21:55 japhb Heh
21:57 FROGGS jnthn: builds fine on linux
21:58 jnthn yay
21:59 * jnthn checked that too, but is glad to have a second conf :)
21:59 FROGGS :o)
22:11 nebuchadnezzar ok, I'll update the debian packaging soon
22:16 dalek moarvm.org: 5696465 | jnthn++ | / (3 files):
22:16 dalek moarvm.org: Update website for 2015.03 release.
22:16 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/5696465bfc
23:50 timotimo .o( but the new data isn't on the website yet? )

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