01:26 llfourn joined 03:23 BinGOs joined
dalek arVM: 3155720 | (Jimmy Zhuo)++ | / (9 files):
expose the backlog arg for listen
 04:11
arVM: 551c87c | (Jimmy Zhuo)++ | / (9 files):
Merge branch 'backlog'

Conflicts: lib/MAST/Ops.nqp
arVM: c3eea17 | (Jimmy Zhuo)++ | src/core/interp.c:
fixed cur_op
 04:28
diakopter JimmyZ: what does this branch do :) 04:33
JimmyZ diakopter: github.com/MoarVM/MoarVM/issues/278 04:36
diakopter: see above :)
04:39 vendethiel joined 07:51 brrt joined
brrt good * #moarvm 07:51
08:04 FROGGS joined
diakopter brrt: hi :D 08:07
brrt hi diakopter 08:09
08:22 FROGGS joined 08:53 FROGGS joined 09:09 japhb joined 09:25 japhb joined 09:28 leont joined 09:46 zakharyas joined 10:29 FROGGS joined 12:31 domidumont joined 12:49 zakharyas joined 13:11 domidumont joined
dalek arVM/even-moar-jit: 74d3bb5 | brrt++ | / (3 files):
Add convergence algorithm for tile rule cost

I'm still not 100% sure that this is the right convergence criterium, but it does work much better than the earlier versions.		 13:48
14:28 pyrimidine joined 16:47 zakharyas1 joined 17:28 leont joined 18:15 leont left, leont joined
leont The error I'm still getting is confusing 18:16
«Missing or wrong version of dependency '/home/leon/Code/rakudo/Foo.pm' (from '/home/leon/Code/rakudo/Foo.pm')»
Depending on yourself is the shortest circle one can make, so that being an error makes sense, the question is why does it think it has this self dependency
backtrace at paste.scsys.co.uk/502430 18:17
18:30 leont joined 18:39 llfourn joined
[Coke] What's in your Foo.pm? 18:43
18:47 domidumont joined
nine Does anyone have suggestions on how to debug "Missing serialize REPR function for REPR MVMContext"? 18:48
18:52 domidumont joined 18:58 leont joined 18:59 hoelzro joined
diakopter nine: weird 19:24
how would an MVMContext get in a P6Opaque slot 19:25
19:29 zakharyas joined 19:34 zakharyas1 joined
nine Is there any way to track down which slot this is? 19:37
diakopter: well the answer to your question is probably my ignorance 19:41
diakopter well the error is in two places
serialization.c and P6Opaque
from which one was it throwing? 19:42
nine at gen/moar/stage2/QAST.nqp:4971 (/home/nine/rakudo/install/share/nqp/lib/QAST.moarvm:serialize_sc:7)
diakopter did you try --ll-exception 19:43
nine diakopter: gist.github.com/niner/de09d9798ae01c348b4f is the patch I'm working on. The first hunk in Perl6/Actions.nqp is probably responsible.
diakopter: do you see anything wrong with that?
diakopter what's the output before it errors 19:44
nine gist.github.com/niner/1285ced3a811451e8fe0 19:45
Test1.pm is: unit module Test1; use Test2; our sub resources() { %?RESOURCES<foo> } 19:46
Test1.pm is just: unit module Test2;
The error disappears if I remove the "use Test2;"
19:46 FROGGS joined
timotimo maybe you need a nqp::getstaticcode somewhere, nine 20:02
nine I guess what I did is at least not completely wrong. Otherwise someone would have said so by now 20:05
20:37 donaldh joined
timotimo i don't really know what MVMContext is for, but i know that nqp::getstaticcode will get you a static code reference rather than a closure-y one 21:19
er ... "i know" may be a bit too strong :) 21:20
21:42 vendethiel joined
jnthn One hack to figure out where the MVMContext is coming from is to tweak it's allocate REPR function to dump out the memory address we allocate it at along with MVM_dump_backtrace 21:55
and then you have the address of the thing we can't serialize so can hunt it down
timotimo neat 21:56
hey jnthn, what would a heap explorer do?
hmm. if i want to start something new maybe i should prefer the coverage tool instead 21:57
nine jnthn: donaldh++ already figured out that it's CompUnit::Handle's $.module_ctx property containing the MVMContext. 22:32
jnthn Ah
nine jnthn: Working theory is: %?RESOURCES is a Distribution::Resource object that references the CompUnit::Repository which has a %.loaded hash that references CompUnits containing CompUnit::Handles referencing the contexts 22:33
That's why it suddenly surfaced
jnthn Sounds like a reasonable theory
nine Unfortunately replacing the module_ctx by the lexpad (which is what we're really interested in) doesn't seem to be enough 22:34
22:38 < FROGGS> nine: sadly using the lexpad there isnt enough... a PseudoStash also has an attribute with a context in it
timotimo jnthn: did you do any design thinking for the coverage analysis tool yet? i was thinking it'd probably be wise to re-use the whole call graph node structure we have for the profiler anyway but just not emit the "allocated", "entered", "left", "osr'd" operations and instead emit "line hit". though perhaps it'd be wiser to just have a flat array of bools for all lines a file may have? 22:39
yeah, it doesn't make much sense to have the call graph involved 22:42
jnthn I was thinking of using annotations
So we can get closer to lines
timotimo right, in the emit/instrument phase we'd emit a "hit this line" op every time we find a filename/line annotation 22:43
that part is clear enough to me
jnthn I think we'll have to log it...somewhere...and then aggregate the data elsewhere 22:44
Becuaes usually you're intersted in coverage of a test suite
Not just one test file
So we need to aggregate data from many test files
timotimo yeah
i think the aggregation can live in a separate tool and we'd just be spitting out lots of files (so that we don't run into TEST_JOBS=9 trouble)
moar_coverage.PID might be good enough 22:45
jnthn PIDs get reused
leont In p5 it's done by essentially replacing all opcodes. I'm recommend coming up with something better…
jnthn leont: We already have something better :)
(Bytecode instrumentation, which we use for profiling)
leont :-) 22:46
jnthn Tteaching + delayed travel = exhausted; sleep & 22:48
nine Replacing module_ctx by the lexpad gets rid of a lot of uglyness in CompUnit::Handle, so it _must_ be more correct 22:50
timotimo gnite jnthn :) 22:51
nine diakopter: thanks for your help! 23:06
23:30 ggoebel7 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!