nine It's the EVAL! 07:46
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
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
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
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...
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
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
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
timotimo jnthn: so should i assume the allocation of the BOOTHash happens inside a non-lowered signature bind or something? 21:22
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!