Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-12-05

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

All times shown according to UTC.

Time Nick Message
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
03:30 dalek joined #moarvm
04:41 pyrimidine joined #moarvm
05:42 pyrimidine joined #moarvm
05:56 pyrimidine joined #moarvm
06:19 pyrimidine joined #moarvm
06:20 flaviusb joined #moarvm
06:48 [Coke]_ joined #moarvm
06:51 domidumont joined #moarvm
06:56 domidumont joined #moarvm
07:01 pyrimidine joined #moarvm
07:05 pyrimidine joined #moarvm
07:31 domidumont joined #moarvm
07:56 nwc10 good o/, #moarvm
08:34 nebuchadnezzar joined #moarvm
08:58 d4l3k_ joined #moarvm
09:38 jnthn o/
09:38 yoleaux2 4 Dec 2016 21:07Z <MasterDuke> jnthn: to go along with the issue AlexDaniel mentioned, here's the backtrace for a segfault. however, i don't know exactly what the code was that caused the segfault, since accidentally we were both editing it at the same time. https://gist.github.com/MasterDuke17/8e1628d62ac4e77e0cb52ac3ffd6ccde
09:41 jnthn That looks awfully like the "sync handles used across threads" issue
09:41 jnthn Except the code doesn't match that hypothesis
09:41 jnthn But maybe did at the time the segfault occurred :P
10:03 dogbert17 o/
10:05 dogbert17 should the problem nwc10 found yesterday be RT'd?
10:05 jnthn Yes, go for it so we don't lose it
10:06 dogbert17 did the ASAN/valgrind output enough info?
10:07 jnthn Well, as much as it's going to, at least
10:08 dogbert17 ok, I'll write it unless nwc10 wants to do it :)
10:08 nwc10 please could you do it
10:08 nwc10 (thanks)
10:08 dogbert17 I'll include all the info that we have, gimme 10 minutes ...
10:28 dogbert17 RT #130266
10:28 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=130266
10:41 * dogbert17 notices that t/spec/S17-supply/start.t still can generate invalid reads once in 5-10 runs /o\
10:44 * dogbert17 and then he remembers that the start.t provlem is a --full-cleanup issue (sorry for the noise)
10:47 timotimo oh
10:47 timotimo good to know
10:48 dogbert17 timotimo: in fact, it was you who figured that out :-)
10:53 timotimo no, i mean, good to know it wasn't a problem with start.t
10:54 dogbert17 agreed :-)
11:31 ggoebel joined #moarvm
15:38 zakharyas joined #moarvm
16:22 cygx joined #moarvm
16:22 cygx o/
16:23 cygx is there a reason why some moarvm ops do seemingly arbitrary copying of their operands?
16:23 cygx eg loadbytecode or bindcurhllsym
16:24 jnthn Historical accident
16:25 jnthn I think originating in that some of them got ported from the JVM codebase
16:25 jnthn (as in, the rakudo-j guts)
16:25 jnthn And those always do return something because it's a stack machine
16:26 jnthn Whereas in MoarVM we just identify in QAST->MAST compilation which operand gets used as the result if you use a void moarop in a non-void context
16:26 jnthn We'll clean it up some day, but probably only when doing some other more dramatic re-work of bytecode stuff.
16:27 jnthn In the meantime, it's not worth the upheavel.
16:27 cygx so the bytecode isn't fixed yet? or will be equivalent ops without the historical quirks be added on top?
16:29 cygx or phrased less weirdly, will moarvm be backwards-compatible with the current (non-spesh) instruction set?
16:29 cygx or is there a breaking change on the horizon
16:29 jnthn Well, whatever we do we'll have to implement backward compatibility to some level, because otherwise we break the NQP bootstrap
16:32 jnthn To be clear, I've no concrete plans for changes in the particularly near future. I know some things I'd like to do differently some day, but there's not enough of them to be even closing to a tipping point yet.
16:32 jnthn *even close
16:33 * TimToady gladly refrains from upheaving
16:36 zakharyas joined #moarvm
16:38 * jnthn suspects that concurrency polishing will keep his Perl 6 tuits largely occupied for the first half of 2017, and a spesh overhaul will then take up another chunk of them... :)
16:39 * cygx is attempting to write a bootstrapped language on top of MoarVM
16:40 cygx not sure when I'll get bored with it, but for now the stage0 compiler is coming along nicely...
16:40 moritz written in NQP?
16:41 cygx an assembler written in NQP, the compiler written in Perl6
16:41 jnthn cygx: Ah, using the MAST layer?
16:42 cygx currently, yes
16:42 cygx the later stages are supposed to generate bytecode directly
16:42 cygx ie eventually, there shouldn't be any dependency on NQP whatsoever
16:44 jnthn Aye, though I guess you're aware that all you really need is objects with the correct shape defined in whatever language for the built-in assembler to stay happy? :)
16:45 cygx I haven't really looked at that part yet, but I saw that the NQP classes are apparently mirrored on the C side
16:45 nwc10 jnthn: so that's the first half and second half spoken for. What's the plan for the third half? :-)
16:45 jnthn Sleep! Cooking curry! Beer! :)
16:45 nwc10 I approve of this plan
16:46 nwc10 sadly my coffers are empty, so there's point in applying to *me* for a grant to enable it :-)
16:49 ilmari nwc10: you're busy sinking their contents into a hole in the ground?
16:49 nwc10 yes-ish
16:49 nwc10 it's a hole with negative depth now
16:49 nwc10 you pay a lot of money to dig a hole
16:50 nwc10 and then a lot more money to fill it in again
16:50 nwc10 as of today, it's a hole with a water supply. At least as far as the meter chamber at the front
16:51 nwc10 but no power, windows, tiles on the roof or a bunch of other stuff
16:54 jnthn Yes, but does it have internet yet? :P
16:56 nwc10 For some value (I don't think that it has a tin-foil hat inside the roof)
16:57 nwc10 I have two Pringles cans ready in the garage here (for backhaul)
16:57 nwc10 but not yet tested
17:11 babydrop FWIW, rakudo/pull/934 exposes a spesh problem: https://github.com/rakudo/rakudo/pull/934#issuecomment-264913801
17:12 * babydrop looks at generated MVM_SPESH_LOG
17:12 babydrop yikes... gonna be at least a year before I'm at that level :(
17:15 jnthn babydrop: It vanishes with MVM_SPESH_DISABLE?
17:16 babydrop Yeah
17:16 babydrop Or if you set MVM_SPESH_LIMIT to 863 or lower
17:16 jnthn You may also try MVM_SPESH_INLINE_DISABLE, MVM_SPESH_OSR_DISABLE, and MVM_JIT_DISABLE (one at a time)
17:17 jnthn (and in place of MVM_SPESH_DISABLE)
17:17 jnthn That disables 3 different pieces and can narrow it down further (or eliminate them from consideration)
17:17 babydrop I did the first two (bug was still there). Lemme try the jit one
17:19 babydrop Still there with MVM_JIT_DISABLE=1
17:19 jnthn OK, well, there's 3 big chunks of the code eliminated...
17:19 babydrop Dissapears with  MVM_SPESH_NODELAY=1
17:20 jnthn That doesn't tell us that much, sadly
17:20 babydrop :(
17:20 jnthn The limit otoh means we can figure out which piece of code gets mis-optimized
17:20 babydrop \o/
17:21 jnthn (The last one in the spesh log, usually)
17:26 pyrimidine joined #moarvm
17:29 babydrop This is the log with http://temp.perl6.party/spesh.log.txt for when MVM_SPESH_LIMIT=864
17:31 jnthn TIL don't open huge text files in chrome :P
17:31 babydrop oops :}
17:32 jnthn (It didn't bring it down, it just got very laggy trying to scroll the thing)
17:32 jnthn (Which woulda been semi-excusable if it'd rendered the text, rather than present me with a blank white space :P)
17:39 jnthn Yeah, the routine in question is quite big, so will take a bit of time to try and figure out
17:39 jnthn And more brane than I have right now :)
17:42 jnthn dinner &
18:04 pyrimidine joined #moarvm
18:18 domidumont joined #moarvm
18:41 ggoebel joined #moarvm
18:50 FROGGS joined #moarvm
19:04 synopsebot6 joined #moarvm
19:07 synopsebot6 joined #moarvm
19:22 nebuchadnezzar joined #moarvm
19:23 nwc10_ joined #moarvm
19:33 geekosaur joined #moarvm
19:48 lizmat joined #moarvm
19:49 dalek joined #moarvm
20:19 pyrimidine joined #moarvm
22:50 stmuk_ joined #moarvm

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