00:05
vendethiel joined
01:19
raiph joined
|
|||
raiph | stefan-marr.de/papers/pldi-marr-et-...ogramming/ | 01:20 | |
"Dispatch chains are a generalization of polymorphic inline caches ... and allow optimization of metaprogramming at the virtual machine level." | 01:21 | ||
01:22
Ven joined
01:48
ilbot3 joined
02:02
Ven joined
02:06
vendethiel joined
03:08
vendethiel joined
08:21
Ven joined
08:43
mj41 joined
09:34
Ven joined
|
|||
jnthn | Yay, valgrind spots the same explode ASAN did too | 10:36 | |
11:00
ggoebel joined
|
|||
dalek | arVM: 2d09987 | jnthn++ | / (9 files): Fix use-after-free if hash iter block frees nodes. |
11:02 | |
jnthn | yay, clean valgrind is clean | 11:06 | |
Urgh...but loads of fail in spectest | 11:12 | ||
arnsholt | Code depending on hash ordering perhaps? | 11:14 | |
jnthn | No, SEGVs... | 11:15 | |
arnsholt | Oh. Not hash ordering then, I agree =) | 11:21 | |
jnthn | Something very strange/confusing. | 12:15 | |
12:28
vendethiel joined
|
|||
dalek | arVM: fcf977f | jnthn++ | 3rdparty/uthash.h: Be consistent with paren-ing in macro. |
12:30 | |
arVM: f323d27 | jnthn++ | src/6model/reprs/MVMHash. (2 files): Eliminate a single-use macro. |
|||
arVM: 0c052ea | jnthn++ | 3rdparty/uthash.h: Correct head replacement logic. Apparently, I need my head logic replaced... If we have a hash with only one bucket filled with two things in the same bucket, we of course need to consider both items in the bucket when seeking a replacement head if the head gets deleted. |
12:51 | ||
jnthn | That took altogether too long to find... | 12:52 | |
nwc10 | OK, so I should test *that* one? :-) | ||
jnthn | Please. Valgrind is quiet on the spectests I've thrown at it that exploded before. | ||
ut_hash is horrible to debug since it's a load of macros | |||
They are in serious danger of being replaced by static inlines. :) | |||
nwc10 | I was wondering whether it's viable/time to replace it with | 12:53 | |
what you said | |||
jnthn | Not *trivially*, but should be possible | ||
nwc10 | jnthn: was that a bug in your changes/additions to UThash, or the original code? | 12:57 | |
12:58
rurban joined
|
|||
jnthn | nwc10: My changes | 13:00 | |
nwc10: It had logic that solved the same problem, but it used the addition order chain, which I was getting rid of | |||
nwc10 | aha, that explains a lot | 13:01 | |
jnthn | Anyway, will leave you to do the ASAN run and have a (later than intended) lunch now I've debuggered that issue... | 13:11 | |
nwc10 | t/spec/S17-promise/allof.t and t/spec/integration/advent2013-day14.t appear to be flapping under ASAN, but that's not new news. | 13:18 | |
everything else passes | |||
"We have normality. I repeat, we have normality. Anything you still can't cope with is therefore your own problem." | |||
jnthn++ # well earned lunch | |||
13:33
rurban joined
13:40
mj41 joined
13:53
rurban joined
13:57
vendethiel joined
14:33
rurban joined,
rurban left
15:43
zakharyas joined
16:08
rurban joined
18:04
vendethiel joined
19:00
vendethiel- joined
19:14
FROGGS[mobile] joined
19:22
zakharyas joined
21:28
vendethiel joined
21:34
TimToady joined
|
|||
timotimo | i am going to put valgrind annotations into the allocators we have so that helgrind and drd output more sensible descriptions of the allocated chunks | 23:04 | |
we *could* introduce redzone support into our allocators, too | 23:05 | ||
23:12
vendethiel joined
|