[00:00] *** japhb joined
[00:10] *** quotable6 joined
[00:32] *** Kaiepi joined
[02:09] <AlexDaniel> squashable6: next

[02:10] <squashable6> AlexDaniel, ⚠🍕 Next SQUASHathon in 2 days and ≈7 hours (2018-02-03 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day

[02:12] *** nativecallable6 joined
[02:15] *** nativecallable6 joined
[02:40] *** nativecallable6 joined
[02:56] *** nativecallable6 joined
[02:58] *** ilbot3 joined
[03:05] *** Kaiepi joined
[03:06] *** dogbert11 joined
[03:08] *** Kaiepi joined
[06:52] *** brrt joined
[06:56] <brrt> good * #moarvm

[07:01] <brrt> maybe we disable box_i and bos_s for the moment

[07:15] *** domidumont joined
[07:47] *** brrt joined
[08:11] *** domidumont joined
[08:18] *** brrt joined
[08:40] *** zakharyas joined
[08:47] *** zakharyas joined
[08:55] *** AlexDaniel joined
[09:16] *** zakharyas joined
[09:31] <AlexDaniel> squashable6: next

[09:31] <squashable6> AlexDaniel, ⚠🍕 Next SQUASHathon in 2 days and ≈0 hours (2018-02-03 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day

[10:25] *** zakharyas joined
[10:49] *** lizmat joined
[11:04] *** brrt joined
[11:26] *** greppable6 joined
[11:56] *** zakharyas joined
[13:10] *** domidumont joined
[13:12] <MasterDuke> brrt: right now there is no template for box_s. i tested one, but since it caused the rakudo build failure i didn't include it in the PR

[13:13] <MasterDuke> but if box_i is causing problems then yeah, it should be disabled

[13:16] *** domidumont joined
[13:17] *** zakharyas joined
[13:19] *** zakharyas joined
[13:55] *** zakharyas joined
[14:07] *** colomon_ joined
[14:42] *** domidumont joined
[14:43] *** domidumont joined
[14:44] *** domidumont joined
[14:50] *** domidumont joined
[14:51] *** domidumont1 joined
[15:14] <MasterDuke> brrt: how does https://github.com/MoarVM/MoarVM/pull/792 look?

[15:15] <brrt> it leaves me wondering, for one thing, if we can make the MVM_SC_WB_OBJ thing a macro

[15:16] <brrt> and maybe a (^repr_op $obj name) macro

[15:16] <brrt> but other than that, it certainly looks sane :-)

[15:16] <brrt> does it work? :-D I can't tell from the code

[15:17] <brrt> oh,

[15:17] <MasterDuke> yeah, i was starting to think about macros for some stuff also, it was getting a bit repetitive

[15:17] <MasterDuke> it? the PR? yeah

[15:18] <brrt> (^getf $found MVMRegister o) - thats… cute, but porbably redundant, should probably be just (load) - but then again, if it works,  i have no objections

[15:18] <brrt> i would just be amazed if it did work because MVMRegister is a union

[15:18] <brrt> i never tried that

[15:18] <MasterDuke> well, it passed all the tests

[15:19] <MasterDuke> i didn't try exercising specific functionality

[15:19] <brrt> hmm. no. and we might want a systematic solution for that anyway

[15:19] <brrt> but it looks good to me (on first blush, anyway)

[15:20] <MasterDuke> cool

[15:41] *** zakharyas joined
[15:43] *** zakharyas joined
[15:58] *** [Coke] joined
[16:07] *** brrt joined
[16:33] *** MasterDuke joined
[16:41] *** brrt joined
[17:23] *** Kaiepi joined
[18:00] *** domidumont joined
[18:04] *** zakharyas joined
[18:12] *** MasterDuke joined
[18:54] *** domidumont joined
[19:16] *** nativecallable6 joined
[19:58] *** brrt joined
[20:02] <samcv> woo squashathon in two day

[20:02] *** evalable6 joined
[20:11] *** Kaiepi joined
[20:12] <brrt> good *

[20:18] <jnthn> evenin' all o/

[20:20] <brrt> \o jnthn

[20:20] <brrt> jnthn++ good post

[20:20] <MasterDuke> brrt: any objection to merging my latest PR? i think once that is merged i'll look into your comments on the sp_findmeth one, as well as looking for good macro candidates in what's existing

[20:20] <brrt> none

[20:21] <brrt> i haven't done it myself because i'm hunting a bug. and i have it covered now

[20:21] <brrt> (i know what the bug is)

[20:21] <MasterDuke> nice

[20:22] <brrt> yeah. what's not nice is that i already solved this, but only for the jit-expr-optimizer branch 😬

[20:22] <MasterDuke> wish i could help with fixing bugs, but at this point i think inadvertently stumbling across them is the most i can do

[20:22] <brrt> hehe, that's plenty

[20:22] <brrt> although, have i told you about how jit-bisect.pl works

[20:22] <MasterDuke> is that branch almost ready for merging?

[20:23] <MasterDuke> don't think so

[20:23] <brrt> we could merge it, yes, but i want a few more things about it

[20:24] <MasterDuke> is the bug related to the box_* stuff?

[20:26] <brrt> nope

[20:26] <MasterDuke> is jit-bisect.pl for finding bugs in the jit code itself? or in templates?

[20:27] <brrt> well, it finds a problem in miscompiled code

[20:27] <brrt> that may be the jit compiler or in the templates, or even in the tiles

[20:28] <brrt> as long as it ends up in the compiled code, it can point it out

[20:28] <brrt> (not always obviously though)

[20:29] <brrt> this is the elegant bit about a JIT compiler

[20:30] <brrt> yep, my patch fixes the bug in my sp_findmeth version

[20:30] <brrt> that version is still wrong, so … :-)

[20:32] <MasterDuke> and since we're not playing horseshoes or handgrenades, i guess one bug closer to correct isn't correct enough

[20:33] <brrt> nope. but i'm glad that it works

[20:34] <brrt> there's no other bug hiding in the shaodws

[20:36] <geekosaur> .oO { 99 bugs in the code.. take one down, patch it around, 101 bugs in the code }

[20:45] <Geth> ¦ MoarVM: 9a2d346762 | (Bart Wiegmans)++ | 2 files

[20:45] <Geth> ¦ MoarVM: Add NOOP expr operator

[20:45] <Geth> ¦ MoarVM:

[20:45] <Geth> ¦ MoarVM: During the tiling process we sometimes add tiles for the labels in

[20:45] <Geth> ¦ MoarVM: conditional expressions, that have no operator associated. However,

[20:45] <Geth> ¦ MoarVM: the operator in memory would then be 0, which is a valid operator type.

[20:45] <Geth> ¦ MoarVM:

[20:45] <Geth> ¦ MoarVM: That didn't matter until I changed the order of LOAD and COPY, since COPY

[20:45] <Geth> ¦ MoarVM: <…commit message has 9 more lines…>

[20:46] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9a2d346762

[20:46] <Geth> ¦ MoarVM: 7434f5e334 | (Bart Wiegmans)++ | 2 files

[20:46] <Geth> ¦ MoarVM: Add CHECK_RETURN guard node

[20:46] <Geth> ¦ MoarVM:

[20:46] <Geth> ¦ MoarVM: Specially for sp_findmeth, which can be clever about it (returns a

[20:46] <Geth> ¦ MoarVM: value to indicate its invokishhness). I didn't add that template

[20:46] <Geth> ¦ MoarVM: though because, not being marked invokish, it would not correctly

[20:46] <Geth> ¦ MoarVM: flush values to memory during processing.

[20:46] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7434f5e334

[20:59] *** Kaiepi joined
[21:02] *** travis-ci joined
[21:02] <travis-ci> MoarVM build failed. Bart Wiegmans 'Add CHECK_RETURN guard node

[21:02] <travis-ci> https://travis-ci.org/MoarVM/MoarVM/builds/335816437 https://github.com/MoarVM/MoarVM/compare/783a4f07c7dd...7434f5e334ca

[21:02] *** travis-ci left
[21:18] *** zakharyas joined
[21:44] *** zakharyas joined
[22:54] *** Kaiepi joined
[22:59] *** evalable6 joined
[23:03] *** _Kaiepi joined