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

Powered by Cro and the Raku® Programming Language.

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

Thank you!