Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-14

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

All times shown according to UTC.

Time Nick Message
00:05 vendethiel joined #moarvm
00:43 geekosaur joined #moarvm
02:01 FROGGS_ joined #moarvm
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
02:51 vendethiel joined #moarvm
06:45 JimmyZ joined #moarvm
07:16 sivoais joined #moarvm
07:16 avar joined #moarvm
07:17 vendethiel joined #moarvm
07:18 domidumont joined #moarvm
07:45 FROGGS joined #moarvm
07:46 nine It's the EVAL!
07:46 vendethiel joined #moarvm
07:46 nwc10 good *, #moarvm
07:50 nine I use .perl to serialize a DependencySpecification. When I need to check if a precomped dependency is still up to date I EVAL this to get the DependencySpecification object back and re-run dependency resolution. This is what screws up the precompiled modules somehow.
07:52 nine The difference between precomp on installation and precomp on first load is just that in the latter case I know that the dependencies are up to date and don't have to check.
07:54 FROGGS nine: yes, EVAL causes a lot of trouble in the precomp process
07:54 FROGGS nine: so probably Panda::Common depends on that EVAL CU when you precompile it, but it wont be there once you load it (or something like that)
07:55 FROGGS nine: the reason I switched to JSON was that EVAL broke CURLI
07:57 domidumont joined #moarvm
08:10 nine Is there any way to prevent the CU from depending on the EVAL SC? There shouldn't be any references to the deserialized object anywhere.
08:16 FROGGS no, I dont think so
08:17 FROGGS precomping is kinda "slurpy" in that regard
08:17 FROGGS is there no way to work around that EVAL?
08:18 nine Well I have to serialize/deserialize a DependencySpecification object. This may contain strings, versions, version ranges, regexes and other serializeable and smartmatchable things.
08:23 FROGGS joined #moarvm
08:23 zakharyas joined #moarvm
08:23 FROGGS no, I dont think so
08:23 FROGGS precomping is kinda "slurpy" in that regard
08:23 FROGGS is there no way to work around that EVAL?
08:29 nine Well I have to serialize/deserialize a DependencySpecification object. This may contain strings, versions, version ranges, regexes and other serializeable and smartmatchable things.
08:29 nine The only alternative I would see is defining a subset that we want to support and implement serialization of those. This may be the long term solution anyway but I'd have liked to avoid it for now until we have a better idea about real life use cases.
08:33 FROGGS just wanna say that I had banged my head against EVAL in the precomp process for many many hours already
08:33 FROGGS avoid it
08:33 nine Thanks for the advise :)
08:33 nine So it's plan B then...
08:35 FROGGS we need that subset for panda's command lines and for handling META6.json files anyway
08:37 nine Yes, if any non-Perl6 tool should have a chance of processing our dependency information, we need it. It's just that if I go with what's currently in use, we end up with just storing the short-name as-is :)
08:40 FROGGS where is that EVAL ooc?
08:48 nine https://github.com/rakudo/rakudo/blob/relocateable-precomp/src/core/CompUnit/PrecompilationRepository.pm#L89
08:49 FROGGS[mobile] joined #moarvm
08:50 FROGGS[mobile] nine: where is that EVAL? in rakudo or panda?
08:51 nine in rakudo
08:51 nine https://github.com/rakudo/rakudo/blob/relocateable-precomp/src/core/CompUnit/PrecompilationRepository.pm#L89
08:51 FROGGS[mobile] ahh, different branch...
09:09 FROGGS[mobile]2 joined #moarvm
09:40 jnthn At the moment, if you do an EVAL, while compiling, it gets its own SC, its constants etc. end up in that, and it then gets lost
09:41 jnthn That's already filed in RT iirc
10:37 vendethiel joined #moarvm
13:18 zakharyas joined #moarvm
13:37 Ven joined #moarvm
13:38 vendethiel joined #moarvm
14:36 Ven joined #moarvm
14:44 Ven joined #moarvm
14:55 Ven joined #moarvm
14:57 vendethiel joined #moarvm
15:00 Ven joined #moarvm
15:03 Ven joined #moarvm
15:40 Ven joined #moarvm
15:43 Ven joined #moarvm
15:51 Ven joined #moarvm
16:05 Ven joined #moarvm
16:11 Ven joined #moarvm
16:24 Ven joined #moarvm
16:29 mojca joined #moarvm
18:12 dalek MoarVM: 1e3d2ac | jnthn++ | src/jit/emit_x64.dasc:
18:12 dalek MoarVM: Fix JIT compiler bug in string le/ge ops.
18:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1e3d2ac307
18:15 timotimo d'oh!
18:21 domidumont joined #moarvm
18:24 TimToady found it running a Real Programâ„¢
18:24 TimToady well, I wasn't the only one to find it, I guess...
18:24 TimToady since there was an RT
18:51 cognominal joined #moarvm
19:17 vendethiel joined #moarvm
19:43 lizmat joined #moarvm
21:22 timotimo jnthn: so should i assume the allocation of the BOOTHash happens inside a non-lowered signature bind or something?
21:50 geekosaur joined #moarvm
23:09 timotimo so, moar --dump will get a "resource temporarily unavailable" from write, and printf happily returns that
23:09 timotimo likely some state set up by libuv on the stdout
23:10 mojca joined #moarvm
23:29 timotimo well, i've written a loop of writes
23:34 dalek MoarVM: 4b3baea | timotimo++ | src/moar.c:
23:34 dalek MoarVM: handle nonblocking stdout properly for --dump
23:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4b3baea572
23:34 dalek MoarVM: b152c2c | timotimo++ | src/core/bytecodedump.c:
23:34 dalek MoarVM: our linelocs buffer in bytecode dumping was a bit too small
23:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b152c2c865
23:39 timotimo i think the next thing i'll do is give wval and wval_wide in the spesh log the debug_name
23:59 dalek MoarVM: 4ade6d6 | timotimo++ | src/spesh/dump.c:
23:59 dalek MoarVM: extract info out of wval/wval_wide referenced objects
23:59 dalek MoarVM:
23:59 dalek MoarVM: shows the REPR's name and - if it is set - the debug_name.
23:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ade6d6db4

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