|
01:17
benabik joined
01:55
JimmyZ_ joined
|
|||
| JimmyZ | .tell jnthn 80f8b533e9 seems not needed, since it's already flatten in MVM_string_concatenate | 01:57 | |
|
02:29
[Coke] joined
02:39
ggoebel110 joined
04:49
ssutch joined
06:39
FROGGS[mobile] joined
09:38
woolfy joined
09:56
tgt joined
10:07
woolfy left
10:12
FROGGS[mobile] joined
|
|||
| moritz | jnthn: perlpunks.de/paste/show/529c6157.2e6c.3c5 # moar results from building the setting under valgrind | 10:31 | |
| arnsholt | Is that the entire output from a setting compile? | 10:32 | |
| moritz | not quite; I've removed some duplicates, and not included those that I pasted yesterday | 10:33 | |
| arnsholt | Right | 10:34 | |
| jnthn | moritz: Many thanks. I'm gonna focus on indy stuff first today, plus a dentist trip :/ But will see if I can track them donw a bit later. | 10:35 | |
| moritz | arnsholt: ==26861== For counts of detected and suppressed errors, rerun with: -v | ||
| ==26861== Use --track-origins=yes to see where uninitialised values come from | |||
| ==26861== ERROR SUMMARY: 59 errors from 7 contexts (suppressed: 2 from 2) | |||
| arg | |||
| pastefail | |||
| arnsholt | 59 errors? That's not very many at all | 10:36 | |
| moritz | perlpunks.de/paste/show/529c6271.2e6c.172 # that's the whole thing | ||
| arnsholt | Yeah, that's really impressive actually | ||
| jnthn | Still 59 too many :P | 10:38 | |
| nwc10 | moritz: I also see this. | ||
| moritz | nwc10: you also valground rakudo/moar-support? | ||
| arnsholt | The base64_encode ones is probably a local or something like that, I think | 10:39 | |
| nwc10 | yes, but actually I don't see those first errors | ||
| __GI___strncasecmp_l | |||
| that *might* be a glibc vs valgrind thing. Had this on OSX - the system C library "knows" that malloc always allocates 8 byte chunks, so read 8 bytes | 10:40 | ||
| valgrind got uppity | |||
| arnsholt | Yeah, that sounds like it could trigger that kind of error | 10:41 | |
| nwc10 | oh, I'm building with -g | ||
| so I get line numbers | |||
| arnsholt | And I guess we can sort of ignore most of the memory leak statistics valgrind outputs | 10:42 | |
| jnthn | arnsholt: For now. At some point, it'd be good to work on those. | 10:44 | |
| arnsholt | Definitely. But the GC probably generates a lot of false positives | 10:46 | |
| But there's an ignore mechanism I think, which'll can probably cut down on those | |||
| Modulo grammar | 10:47 | ||
| jnthn | The Moar GC is precise, so shouldn't do too badly in that regard, I think. | 10:49 | |
| Doesn't do stack scanning for example | 10:50 | ||
| arnsholt | Oh, cool | 10:51 | |
| nwc10 | the moar GC seems to generate no "noise" (because it is precise)(this is cool) | 10:58 | |
|
12:36
FROGGS joined
|
|||
| diakopter | jnthn: "Ugh, next one seems weird..."? | 12:51 | |
| FROGGS | hehe | 12:52 | |
| yeah | |||
| it scared him into his bed :o) | |||
|
13:03
ggoebel110 joined
|
|||
| jnthn | Well, it looked a bit like a closure serialization bug... | 13:52 | |
| diakopter | (probably my error then :) | 14:08 | |
|
14:36
jnap joined
15:14
cognominal joined
|
|||
| FROGGS | jnthn: do you know why stage post takes 1/3 of past but stage mast takes more time than parse? | 18:36 | |
|
18:38
colomon joined
|
|||
| jnthn | FROGGS: Looks to me because the optimizations of closure handling in the GC are NYI, so it's doing a conservative/correct but unscalable thing at the moment, which makes each run successively more expensive. | 18:47 | |
| (If more closures come to be, at least.) | |||
| Otherwise it's just costly :) | |||
| 'cus of what was accumulated so far. | |||
| FROGGS | ahh, nice to know | ||
| jnthn | So, provided that's what it is, I don't think it's something terrible about the mast stage itself. | 18:48 | |
| FROGGS | cool :o) | ||
| (that is what I wanted to hear) | |||
|
19:01
colomon joined
19:58
dalek joined
20:19
dalek joined
21:12
ggoebel111 joined
22:07
lizmat joined
23:44
woolfy joined
|
|||