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