|
00:05
vendethiel joined
00:43
geekosaur joined
02:01
FROGGS_ joined
02:48
ilbot3 joined
02:51
vendethiel joined
06:45
JimmyZ joined
07:16
sivoais joined,
avar joined
07:17
vendethiel joined
07:18
domidumont joined
07:45
FROGGS joined
|
|||
| nine | It's the EVAL! | 07:46 | |
|
07:46
vendethiel joined
|
|||
| nwc10 | good *, #moarvm | 07:46 | |
| 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:50 | |
| 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:52 | ||
| FROGGS | nine: yes, EVAL causes a lot of trouble in the precomp process | 07:54 | |
| 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) | |||
| nine: the reason I switched to JSON was that EVAL broke CURLI | 07:55 | ||
|
07:57
domidumont joined
|
|||
| 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:10 | |
| FROGGS | no, I dont think so | 08:16 | |
| precomping is kinda "slurpy" in that regard | 08:17 | ||
| is there no way to work around that EVAL? | |||
| 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:18 | |
|
08:23
FROGGS joined,
zakharyas joined
|
|||
| FROGGS | no, I dont think so | 08:23 | |
| precomping is kinda "slurpy" in that regard | |||
| is there no way to work around that EVAL? | |||
| 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 | |
| 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. | |||
| FROGGS | just wanna say that I had banged my head against EVAL in the precomp process for many many hours already | 08:33 | |
| avoid it | |||
| nine | Thanks for the advise :) | ||
| So it's plan B then... | |||
| FROGGS | we need that subset for panda's command lines and for handling META6.json files anyway | 08:35 | |
| 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:37 | |
| FROGGS | where is that EVAL ooc? | 08:40 | |
| nine | github.com/rakudo/rakudo/blob/relo...ory.pm#L89 | 08:48 | |
|
08:49
FROGGS[mobile] joined
|
|||
| FROGGS[mobile] | nine: where is that EVAL? in rakudo or panda? | 08:50 | |
| nine | in rakudo | 08:51 | |
| github.com/rakudo/rakudo/blob/relo...ory.pm#L89 | |||
| FROGGS[mobile] | ahh, different branch... | ||
|
09:09
FROGGS[mobile]2 joined
|
|||
| 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:40 | |
| That's already filed in RT iirc | 09:41 | ||
|
10:37
vendethiel joined
13:18
zakharyas joined
13:37
Ven joined
13:38
vendethiel joined
14:36
Ven joined
14:44
Ven joined
14:55
Ven joined
14:57
vendethiel joined
15:00
Ven joined
15:03
Ven joined
15:40
Ven joined
15:43
Ven joined
15:51
Ven joined
16:05
Ven joined
16:11
Ven joined
16:24
Ven joined
16:29
mojca joined
|
|||
| dalek | arVM: 1e3d2ac | jnthn++ | src/jit/emit_x64.dasc: Fix JIT compiler bug in string le/ge ops. |
18:12 | |
| timotimo | d'oh! | 18:15 | |
|
18:21
domidumont joined
|
|||
| TimToady | found it running a Real Program™ | 18:24 | |
| well, I wasn't the only one to find it, I guess... | |||
| since there was an RT | |||
|
18:51
cognominal joined
19:17
vendethiel joined
19:43
lizmat joined
|
|||
| timotimo | jnthn: so should i assume the allocation of the BOOTHash happens inside a non-lowered signature bind or something? | 21:22 | |
|
21:50
geekosaur joined
|
|||
| timotimo | so, moar --dump will get a "resource temporarily unavailable" from write, and printf happily returns that | 23:09 | |
| likely some state set up by libuv on the stdout | |||
|
23:10
mojca joined
|
|||
| timotimo | well, i've written a loop of writes | 23:29 | |
| dalek | arVM: 4b3baea | timotimo++ | src/moar.c: handle nonblocking stdout properly for --dump |
23:34 | |
| arVM: b152c2c | timotimo++ | src/core/bytecodedump.c: our linelocs buffer in bytecode dumping was a bit too small |
|||
| timotimo | i think the next thing i'll do is give wval and wval_wide in the spesh log the debug_name | 23:39 | |
| dalek | arVM: 4ade6d6 | timotimo++ | src/spesh/dump.c: extract info out of wval/wval_wide referenced objects shows the REPR's name and - if it is set - the debug_name. |
23:59 | |