|
00:04
tadzik joined
00:19
cognominal joined
00:21
tadzik joined
03:41
colomon joined
07:36
domidumont joined
07:41
domidumont joined
|
|||
| dalek | arVM/even-moar-jit: 48f0e19 | jnthn++ | src/core/fixedsizealloc.c: Fix accidental disabling of Fixed Size Allocator. |
08:55 | |
| arVM/even-moar-jit: a0869ee | jnthn++ | docs/ChangeLog: ChangeLog for 2016.02. |
|||
| arVM/even-moar-jit: e4a316a | jnthn++ | VERSION: Bump VERSION. |
|||
| arVM/even-moar-jit: f8b82c5 | brrt++ | / (3 files): Merge remote-tracking branch 'origin/master' into even-moar-jit |
|||
| MoarVM/even-moar-jit: 071e5c6 | brrt++ | src/jit/ (5 files): | |||
| MoarVM/even-moar-jit: Add logging of tile list, pseudotiles for ALL/ANY | |||
|
09:15
FROGGS joined
10:23
kjs_ joined
10:50
vendethiel joined
12:18
vendethiel joined
12:55
vendethiel joined
13:43
brrt joined
|
|||
| brrt | good * | 13:43 | |
| FROGGS | whatever | 13:59 | |
| :P | |||
| jnthn: if I MVMROOT root, do I have to re-obtain body at all when body is OBJECT_BODY(root)? | 14:09 | ||
| I thought MVMROOT-ing stuff makes things *not* move | |||
| jnthn | FROGGS: No, MVMROOT-ing things means the address will be updated if the GC moves it | 14:40 | |
| That is, it adds the address as a temporary root | |||
| brrt | (good to know that) | 14:47 | |
| something is off with my values, which are not set correctly | |||
| otherwise, alsmost back at safe compilation with linearised tiles | 14:48 | ||
| timotimo | yay | 14:50 | |
| jnthn | brrt++ | ||
| jnthn should be returning to more active Moar/Rakudo hacking from next week :) | |||
| brrt | it's just kind of sad i have to spend time fixing a register allocation systme that i know i insufficient | 14:51 | |
| *is | 14:52 | ||
|
15:53
brrt joined
|
|||
| 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? | ||
| jnthn | nine: That looks like epic corruptio | 16:06 | |
| *corruption | |||
| 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 :) | ||
| timotimo | yeah, i don't think it'd ever voluntarily try to put the name of a sub there | ||
| nine | Also I'm not sure where exactly it would find this outdated dependency... | 16:08 | |
| Is the memory/disk layout of precomp files documented somewhere? | 16:09 | ||
| timotimo | hm, that one environment variable we've got for module loading and such doesn't help, eh? | 16:11 | |
| 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:12 | |
| 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:13 | |
| 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? | ||
| nine | jnthn: thanks! I'm gonna have a look. | ||
| 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:17 | ||
| jnthn | "link statically" isn't true in the "we copy all the things" sense | 16:19 | |
| Only repossessed objects end up with their own copy | |||
| It actually is dynamic to some degree | 16:20 | ||
| A module's precomp file will reference things in the CORE.setting, for example | |||
| But it references them by index | |||
| 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 | ||
| 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 | ||
| jnthn | Right :) | ||
| And we'd *still* have to link | |||
| Otherwise one module's Int would not be equivalent to another's | |||
| 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 | ||
| It's not like in, say, C#, where every class fits into a single namespace | |||
| nine | Makes sense, yes. | 16:24 | |
| 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. | 16:54 | ||
|
17:04
kjs_ joined
17:19
Ven joined
17:23
kjs_ joined
17:30
zakharyas joined
|
|||
| 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:28 | |
| hm. though i guess that kind of problem mostly happens in the mainline | 19:29 | ||
|
19:45
Ven joined
|
|||
| FROGGS | also in EXPORT subs | 19:46 | |
| 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:49 | |
| FROGGS | it would certainly help | 19:50 | |
|
20:10
dalek joined
20:44
Ven joined
20:56
Ven joined
|
|||
| jnthn | I'm not sure that will work out | 21:12 | |
| Because the exception probably wasn't serialized due to a direct mention | |||
| But due to being referenced by something that was mentioned | |||
| timotimo | mhh | 21:32 | |
|
21:37
nwc10 joined,
nebuchad` joined
22:06
ilbot3 joined
22:07
Util_ joined,
camelia joined,
mst joined
22:08
[Coke] joined,
arnsholt joined,
moritz joined
22:09
leedo joined
22:13
nwc10 joined
22:17
pyrimidi_ joined
22:19
konobi joined
22:23
nebuchad` joined
22:25
[Coke]_ joined
22:27
lizmat_ joined,
vendethiel joined
22:28
synopsebot6 joined,
dalek joined,
flussence joined
22:29
jnthn joined
22:30
masak joined,
dalek joined,
TimToady joined
22:33
orbus joined
22:37
flussenc1 joined,
_longines joined
22:44
mst joined
23:19
lizmat joined
23:20
leedo joined
23:25
sivoais joined
23:26
[Coke] joined,
tony-o joined
23:32
sivoais joined,
dalek joined
|
|||