00:15 vendethiel joined 01:04 vendethiel joined 02:47 ilbot3 joined 02:51 vendethiel joined 03:31 colomon joined 07:19 ggoebel joined 07:36 rurban joined 07:46 Ven joined 07:52 Ven joined 07:54 FROGGS joined 08:00 Ven joined 08:11 Ven joined, zakharyas joined 08:41 donaldh joined 08:57 virtualsue joined 09:03 virtualsue_ joined 09:29 kjs_ joined 10:35 colomon joined 10:50 Ven joined 11:06 vendethiel joined 12:22 vendethiel joined 12:53 virtualsue joined 13:03 vendethiel joined 13:25 brrt joined 13:44 vendethiel joined 15:02 njmurphy joined 15:12 Ven joined
dalek arVM: ec72fc0 | coke++ | docs/release_guide.md:
Add a note about macport updates to the guide

But seriously, just ping me for now, that's fine.
15:43
arVM: e8d891c | coke++ | ports/macports/Portfile:
track latest changes to make portfile function

Ionic++
16:27 Ven joined 17:15 kjs_ joined 17:30 Ven joined 18:02 colomon joined
dalek arVM: f1c138f | timotimo++ | src/6model/reprs/P6opaque.c:
bindattrs_s can be spesh'd, too.
18:13
18:30 colomon joined 18:53 colomon joined 19:02 FROGGS joined 19:34 kjs_ joined 19:38 kjs_ joined 19:44 colomon joined 20:18 virtualsue joined 20:42 vendethiel joined 22:10 kjs_ joined 22:31 kjs_ joined
timotimo killing unused guards also doesn't free up space in the deopt table (which is MVM_alloc'd, so a potential win to reclaim stuff there) or the annotations list (where each annotation is spesh_alloc'd, so no win to be had) 22:32
and removing the annotations when killing a log guard that belongs to it would require going through all annotations and fixing up the indices to deopt table entries 22:33
hm, my measurements already show that there exist cases where we end up removing more than 10 log-based guards, but that doesn't count guards that get thrown out because whole BBs have been eliminated 22:45
23:37 lizmat joined
timotimo huh, something's weird about this piece of dump ... 23:54
gist.github.com/timo/bc2b12f65bbced5a7d8a - how does BB 2 end up with "2" as one of its successors?