Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-02-27

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

All times shown according to UTC.

Time Nick Message
00:04 tadzik joined #moarvm
00:19 cognominal joined #moarvm
00:21 tadzik joined #moarvm
03:41 colomon joined #moarvm
07:36 domidumont joined #moarvm
07:41 domidumont joined #moarvm
08:55 dalek MoarVM/even-moar-jit: 48f0e19 | jnthn++ | src/core/fixedsizealloc.c:
08:55 dalek MoarVM/even-moar-jit: Fix accidental disabling of Fixed Size Allocator.
08:55 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/48f0e1900b
08:55 dalek MoarVM/even-moar-jit: a0869ee | jnthn++ | docs/ChangeLog:
08:55 dalek MoarVM/even-moar-jit: ChangeLog for 2016.02.
08:55 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/a0869ee561
08:55 dalek MoarVM/even-moar-jit: e4a316a | jnthn++ | VERSION:
08:55 dalek MoarVM/even-moar-jit: Bump VERSION.
08:55 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e4a316a281
08:55 dalek MoarVM/even-moar-jit: f8b82c5 | brrt++ | / (3 files):
08:55 dalek MoarVM/even-moar-jit: Merge remote-tracking branch 'origin/master' into even-moar-jit
08:55 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/f8b82c5ed1
08:55 dalek MoarVM/even-moar-jit: 071e5c6 | brrt++ | src/jit/ (5 files):
08:55 dalek MoarVM/even-moar-jit: Add logging of tile list, pseudotiles for ALL/ANY
09:15 FROGGS joined #moarvm
10:23 kjs_ joined #moarvm
10:50 vendethiel joined #moarvm
12:18 vendethiel joined #moarvm
12:55 vendethiel joined #moarvm
13:43 brrt joined #moarvm
13:43 brrt good *
13:59 FROGGS whatever
13:59 FROGGS :P
14:09 FROGGS jnthn: if I MVMROOT root, do I have to re-obtain body at all when body is OBJECT_BODY(root)?
14:09 FROGGS I thought MVMROOT-ing stuff makes things *not* move
14:40 jnthn FROGGS: No, MVMROOT-ing things means the address will be updated if the GC moves it
14:40 jnthn That is, it adds the address as a temporary root
14:47 brrt (good to know that)
14:47 brrt something is off with my values, which are not set correctly
14:48 brrt otherwise, alsmost back at safe compilation with linearised tiles
14:50 timotimo yay
14:50 jnthn brrt++
14:50 * jnthn should be returning to more active Moar/Rakudo hacking from next week  :)
14:51 brrt it's just kind of sad i have to spend time fixing a register allocation systme that i know i insufficient
14:52 brrt *is
15:53 brrt joined #moarvm
16:04 FROGGS jnthn: aha
16:04 nine How can loading a precompiled NativeCall error out with "Missing or wrong version of dependency '&return_hash_for'" when return_hash_for is defined _in_ NativeCall?
16:06 jnthn nine: That looks like epic corruptio
16:06 jnthn *corruption
16:07 jnthn nine: It's read a bogus string heap index.
16:07 nine From the work I do it's probably caused by loading an outdated dependency. Still the error is quite confusing :)
16:07 timotimo yeah, i don't think it'd ever voluntarily try to put the name of a sub there
16:08 nine Also I'm not sure where exactly it would find this outdated dependency...
16:09 nine Is the memory/disk layout of precomp files documented somewhere?
16:11 timotimo hm, that one environment variable we've got for module loading and such doesn't help, eh?
16:12 nine We actually have 2: RAKUDO_MODULE_DEBUG=1 RAKUDO_LOG_PRECOMP=1 probably because TimToady didn't know about the former when adding the latter
16:13 jnthn nine: The MoarVM bytecode format is documented under docs/ somewhere, and afaik is up to date. But the serialization blob, which is what you're having issues with, is just a section in there.
16:14 jnthn It's not so well documented, though I think there's a doc in the NQP repo that gives some idea of it
16:14 timotimo hmm. is there actually information that could easily be gleaned from the serialized blob that a moar --dump-serialized-blob could output in human-readable form?
16:14 nine jnthn: thanks! I'm gonna have a look.
16:17 nine And since we're on the topic: I've been wondering for a while why we link precomp files statically but load the dependencies dynamically. Why not include all dependencies in the bytcode file when there's no way a different bytecode file could satisfy the dependency?
16:19 jnthn "link statically" isn't true in the "we copy all the things" sense
16:19 jnthn Only repossessed objects end up with their own copy
16:20 jnthn It actually is dynamic to some degree
16:20 jnthn A module's precomp file will reference things in the CORE.setting, for example
16:20 jnthn But it references them by index
16:21 nine What I mean with that is that there doesn't seem to be any kind of indirection there. Only a 100 % identical bytecode file of a dependency will work.
16:21 jnthn That's not really true. It's not about the bytecode file so much as the serialization blob
16:22 jnthn But yes, that only has the indices level of indirection
16:22 nine But now that I think of it, I guess I can also answer my own question: wouldn't work that well if every bytecode file would include the whole setting or other libraries that are used by multiple modules
16:22 jnthn Right :)
16:22 jnthn And we'd *still* have to link
16:22 jnthn Otherwise one module's Int would not be equivalent to another's
16:23 jnthn The reason we can't be much looser, though, it because in Perl 6 we don't have any absolute name for anything
16:23 jnthn It's not like in, say, C#, where every class fits into a single namespace
16:24 nine Makes sense, yes.
16:54 nine Ok, it's definitely an issue with compilation, not with loading. When I have all NativeCall::* modules be precompiled recursively starting with NativeCall, loading works. When have .install precompile them individually, I get the error on load.
17:04 kjs_ joined #moarvm
17:19 Ven joined #moarvm
17:23 kjs_ joined #moarvm
17:30 zakharyas joined #moarvm
19:28 timotimo so, i'm wondering: when we have an object that we can't serialize, like a VMError or VMException or what it's called, can we go through the bytecode to find what frames refer to the SC Index/ID of that particular object and output these names?
19:29 timotimo hm. though i guess that kind of problem mostly happens in the mainline
19:45 Ven joined #moarvm
19:46 FROGGS also in EXPORT subs
19:49 timotimo i expect it'll be rather a bit of work to get that to give any indication of where things went wrong, so it'd be interesting to know if it'll actually help
19:50 FROGGS it would certainly help
20:10 dalek joined #moarvm
20:44 Ven joined #moarvm
20:56 Ven joined #moarvm
21:12 jnthn I'm not sure that will work out
21:12 jnthn Because the exception probably wasn't serialized due to a direct mention
21:12 jnthn But due to being referenced by something that was mentioned
21:32 timotimo mhh
21:37 nwc10 joined #moarvm
21:37 nebuchad` joined #moarvm
22:06 ilbot3 joined #moarvm
22:06 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
22:07 Util_ joined #moarvm
22:07 camelia joined #moarvm
22:07 mst joined #moarvm
22:08 [Coke] joined #moarvm
22:08 arnsholt joined #moarvm
22:08 moritz joined #moarvm
22:09 leedo joined #moarvm
22:13 nwc10 joined #moarvm
22:17 pyrimidi_ joined #moarvm
22:19 konobi joined #moarvm
22:23 nebuchad` joined #moarvm
22:25 [Coke]_ joined #moarvm
22:27 lizmat_ joined #moarvm
22:27 vendethiel joined #moarvm
22:28 synopsebot6 joined #moarvm
22:28 dalek joined #moarvm
22:28 flussence joined #moarvm
22:29 jnthn joined #moarvm
22:30 masak joined #moarvm
22:30 dalek joined #moarvm
22:30 TimToady joined #moarvm
22:33 orbus joined #moarvm
22:37 flussenc1 joined #moarvm
22:37 _longines joined #moarvm
22:44 mst joined #moarvm
23:19 lizmat joined #moarvm
23:20 leedo joined #moarvm
23:25 sivoais joined #moarvm
23:26 [Coke] joined #moarvm
23:26 tony-o joined #moarvm
23:32 sivoais joined #moarvm
23:32 dalek joined #moarvm

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