00:00 japhb joined 00:10 quotable6 joined 00:32 Kaiepi joined
AlexDaniel squashable6: next 02:09
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 2 days and ≈7 hours (2018-02-03 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day 02:10
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
brrt good * #moarvm 06:56
maybe we disable box_i and bos_s for the moment 07:01
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
AlexDaniel squashable6: next 09:31
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 2 days and ≈0 hours (2018-02-03 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...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
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:12
but if box_i is causing problems then yeah, it should be disabled 13:13
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
MasterDuke brrt: how does github.com/MoarVM/MoarVM/pull/792 look? 15:14
brrt it leaves me wondering, for one thing, if we can make the MVM_SC_WB_OBJ thing a macro 15:15
and maybe a (^repr_op $obj name) macro 15:16
but other than that, it certainly looks sane :-)
does it work? :-D I can't tell from the code
oh, 15:17
MasterDuke yeah, i was starting to think about macros for some stuff also, it was getting a bit repetitive
it? the PR? yeah
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
i would just be amazed if it did work because MVMRegister is a union
i never tried that
MasterDuke well, it passed all the tests
i didn't try exercising specific functionality 15:19
brrt hmm. no. and we might want a systematic solution for that anyway
but it looks good to me (on first blush, anyway)
MasterDuke cool 15:20
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
samcv woo squashathon in two day 20:02
20:02 evalable6 joined 20:11 Kaiepi joined
brrt good * 20:12
jnthn evenin' all o/ 20:18
brrt \o jnthn 20:20
jnthn++ good post
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
brrt none
i haven't done it myself because i'm hunting a bug. and i have it covered now 20:21
(i know what the bug is)
MasterDuke nice
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
brrt hehe, that's plenty
although, have i told you about how jit-bisect.pl works
MasterDuke is that branch almost ready for merging?
don't think so 20:23
brrt we could merge it, yes, but i want a few more things about it
MasterDuke is the bug related to the box_* stuff? 20:24
brrt nope 20:26
MasterDuke is jit-bisect.pl for finding bugs in the jit code itself? or in templates?
brrt well, it finds a problem in miscompiled code 20:27
that may be the jit compiler or in the templates, or even in the tiles
as long as it ends up in the compiled code, it can point it out 20:28
(not always obviously though)
this is the elegant bit about a JIT compiler 20:29
yep, my patch fixes the bug in my sp_findmeth version 20:30
that version is still wrong, so … :-)
MasterDuke and since we're not playing horseshoes or handgrenades, i guess one bug closer to correct isn't correct enough 20:32
brrt nope. but i'm glad that it works 20:33
there's no other bug hiding in the shaodws 20:34
geekosaur .oO { 99 bugs in the code.. take one down, patch it around, 101 bugs in the code } 20:36
Geth MoarVM: 9a2d346762 | (Bart Wiegmans)++ | 2 files
Add NOOP expr operator

During the tiling process we sometimes add tiles for the labels in conditional expressions, that have no operator associated. However, the operator in memory would then be 0, which is a valid operator type.
That didn't matter until I changed the order of LOAD and COPY, since COPY ... (9 more lines)		 20:45
MoarVM: 7434f5e334 | (Bart Wiegmans)++ | 2 files
Add CHECK_RETURN guard node

Specially for sp_findmeth, which can be clever about it (returns a value to indicate its invokishhness). I didn't add that template though because, not being marked invokish, it would not correctly flush values to memory during processing.
20:59 Kaiepi joined 21:02 travis-ci joined
travis-ci MoarVM build failed. Bart Wiegmans 'Add CHECK_RETURN guard node 21:02
travis-ci.org/MoarVM/MoarVM/builds/335816437 github.com/MoarVM/MoarVM/compare/7...34f5e334ca
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!