Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-04-17

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

All times shown according to UTC.

Time Nick Message
03:49 PerlJam joined #moarvm
06:30 brrt joined #moarvm
06:31 FROGGS[mobile] joined #moarvm
06:55 Ven joined #moarvm
07:23 lizmat joined #moarvm
07:36 Ven joined #moarvm
07:38 FROGGS joined #moarvm
07:50 Ven joined #moarvm
07:59 zakharyas joined #moarvm
08:38 Ven joined #moarvm
11:00 brrt joined #moarvm
11:24 timotimo damn, i thought i was being super clever by turning on profiling and enabling the spesh log so that i could get the compiler output from the mast_references test file
11:24 timotimo but it doesn't show up :(
11:25 Ven joined #moarvm
11:25 timotimo possibly something about nesting of compilers and clearing the profiling flag?
11:26 timotimo nothing fixed the "cannot assign to immutable value" problem in the mean time
11:27 * timotimo has no clever idea for debugging this
11:31 timotimo at the same time, i managed to get rid of a brainfart regarding the "let the metamodel compile accessors and BUILDALL methods for us" thing
11:34 brrt waitwhat
11:35 brrt can i help :-)
11:35 timotimo oh, that'd be fantastic
11:35 timotimo you know about local vs localref and lexical vs lexicalref in the QAST::Var :scope?
11:35 brrt ... no
11:35 brrt sorry :-)
11:36 timotimo OK, so at the QAST level we take references to locals by accessing a local with a :scope<localref>
11:36 timotimo that'll be compiled to the proper localref_s operation
11:36 timotimo and working with a variable that was declared :scope<localref> and using that in :scope<local> will decont_s (for example)
11:37 timotimo with that in mind, check out the nqp branch "mast_localref"
11:37 timotimo there's tests in there that fail with the exception "cannot assign to immutable value", and i can't quite figure out how to get at the exact code it's generating
11:38 timotimo you can rebase it onto the newest nqp safely
11:38 timotimo and the test i wrote is in t/moar/02-*.t
11:48 brrt ah ok
11:48 brrt i'll check
11:49 timotimo maybe the op that compiles a MAST tree into a frame or what exactly it is, could be instrumented to dump what it compiles directly after it finishes
11:50 brrt hmm wait
11:51 brrt i think i can help you with that
11:51 brrt have you looked at src/mast/compiler.c
11:54 timotimo no, i just had that idea
12:16 timotimo were you just about to point me at something in particular, or just tell me to read through that file? :)
12:17 brrt i was looking through it myself :-)
12:18 brrt anyway, that's what you could do, i'd guess
12:18 timotimo now let me have a look at what exact function will give me a dump and what struct it expects
12:18 timotimo takes a compunit, i see
12:19 brrt not sure which does mast dumps
12:20 timotimo MVM_vm_dump_file?
12:21 timotimo er ... actually not
12:21 timotimo MVM_bytecode_dump
12:21 timotimo and that uses map_from_file
12:21 timotimo but if we just use nqp::getcomp to compile something, no file gets created
12:44 brrt hmmmpf
12:53 timotimo yes :)
13:02 timotimo i can't get anything to show up in the spesh log even if i execute the compiled code 100 times
13:02 timotimo like, a simple whle loop inside is_qast
13:03 timotimo oh
13:03 timotimo because it dies, duh
13:03 brrt can't you do target=mast
13:04 FROGGS src/strings/unicode_gen.h:112:30: warning: no newline at end of file
13:05 FROGGS src/core/coerce.h:24:93: warning: no newline at end of file
13:05 FROGGS 3rdparty/uthash.h:1001:22: warning: no newline at end of file
13:05 FROGGS (openbsd that is)
13:06 timotimo nope :(
13:07 timotimo https://gist.github.com/timo/e20656ab88afb282a503 - well! this certainly looks very wrong
13:07 timotimo (i'm pretty sure that assign_i should be accessing r1(1), not r2(1) and r2(1) shouldn't exist at all
13:07 timotimo so i sort of know where to look now)
13:08 timotimo kind of looks like an off-by-one error
13:09 brrt doesn't look good, no
13:09 brrt timotimo++
13:12 timotimo or more like a "we asked the register allocator for a fresh register but we shouldn't have"
13:17 brrt that's possible too
13:35 sivoais joined #moarvm
13:35 Ven joined #moarvm
13:58 Ven joined #moarvm
15:41 nebuchadnezzar joined #moarvm
15:46 Ven joined #moarvm
16:00 nwc10 jnthn: I believe that this is the deserialisation bug: http://paste.scsys.co.uk/472836
16:02 nwc10 jnthn: oh wait. PEBKAC. Needs a bit of refinement
16:03 nwc10 neuralise that link...
16:06 nwc10 but there is something very screwball about performance depending on precisely when *(reader->cur_read_offset) is updated
16:11 FROGGS nwc10++ # for hunting this
16:13 nwc10 aargh, I simply can't get it to crash
16:14 FROGGS :o(
16:24 dalek MoarVM: ed6acb2 | FROGGS++ | src/io/syncpipe.c:
16:24 dalek MoarVM: fake POSIX exit codes consequently on windows
16:24 dalek MoarVM:
16:24 dalek MoarVM: We faked these before when the invoked command already had shut down, now
16:24 dalek MoarVM: we also do the right thing when we explicitly close it.
16:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ed6acb2fa1
16:24 dalek MoarVM: a300558 | FROGGS++ | src/io/syncpipe.c:
16:24 dalek MoarVM: remove extra call to uv_run when closing a pipe
16:24 dalek MoarVM:
16:24 dalek MoarVM: This fixes a bug on *BSD, which swallowed the exit code on these platforms.
16:24 dalek MoarVM: I tested this patch on linux, Windows 7 and OpenBSD (successfully).
16:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a300558d5c
17:35 nwc10 jnthn: http://paste.scsys.co.uk/472839
17:41 nwc10 bother, no that's not right either, as the code assumes that nothing trashes reader->root.stables_data
20:53 lizmat_ joined #moarvm
21:10 lizmat joined #moarvm

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