[00:17] *** Kaiepi left [00:17] *** Kaiepi joined [00:17] *** vrurg joined [00:22] *** vrurg left [00:54] *** vrurg joined [00:54] *** vrurg left [00:54] *** vrurg joined [02:23] *** bisectable6 left [02:23] *** statisfiable6 left [02:23] *** greppable6 left [02:23] *** tellable6 left [02:23] *** benchable6 left [02:23] *** unicodable6 left [02:23] *** linkable6 left [02:23] *** evalable6 left [02:23] *** releasable6 left [02:23] *** quotable6 left [02:23] *** coverable6 left [02:23] *** notable6 left [02:23] *** sourceable6 left [02:23] *** bloatable6 left [02:23] *** shareable6 left [02:23] *** nativecallable6 left [02:23] *** committable6 left [02:23] *** squashable6 left [02:24] *** greppable6 joined [02:24] *** linkable6 joined [02:24] *** quotable6 joined [02:24] *** benchable6 joined [02:24] *** squashable6 joined [02:24] *** sourceable6 joined [02:25] *** committable6 joined [02:25] *** evalable6 joined [02:25] *** bisectable6 joined [02:25] *** notable6 joined [02:25] *** statisfiable6 joined [02:25] *** unicodable6 joined [02:26] *** shareable6 joined [02:26] *** coverable6 joined [02:26] *** tellable6 joined [02:26] *** bloatable6 joined [02:26] *** releasable6 joined [02:26] *** nativecallable6 joined [03:50] *** sxmx left [06:52] *** domidumont joined [06:57] *** patrickb joined [06:57] *** sxmx joined [07:43] ¦ MoarVM/master: 4 commits pushed by (Salvador Ortiz)++, MasterDuke17++ [07:43] ¦ MoarVM/master: 1de34262c1 | VMArray: Use dest for select 'kind' in copy_elements [07:43] ¦ MoarVM/master: c66b9e2cca | No need to include d_repr_data in test [07:43] ¦ MoarVM/master: a6238bc24c | VMArray: Remove unneeded tests in aslice. [07:43] ¦ MoarVM/master: f5827e8e09 | Merge pull request #1439 from salortiz/array-copy-into [07:43] ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/598b79e23b3e...f5827e8e098d [07:43] ¦ MoarVM: 726447d71a | (Salvador Ortiz)++ | src/6model/reprs/VMArray.c [07:43] ¦ MoarVM: VMArray: Check slot type for read_buf and write_buf [07:43] ¦ MoarVM: [07:43] ¦ MoarVM: Those operations are only valid when the array_type is of some [07:43] ¦ MoarVM: integer kind. [07:43] ¦ MoarVM: [07:43] ¦ MoarVM: Should closes #1310 [07:43] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/726447d71a [07:43] ¦ MoarVM: c49482208e | MasterDuke17++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c [07:43] ¦ MoarVM: Merge pull request #1440 from salortiz/array-check-slot [07:43] ¦ MoarVM: [07:43] ¦ MoarVM: VMArray: Check slot type for read_buf and write_buf [07:43] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c49482208e [07:43] *** linkable6 left [07:45] *** linkable6 joined [07:48] *** zakharyas joined [08:40] ¦ MoarVM: 0fa3555648 | (Stefan Seifert)++ | src/moar.c [08:40] ¦ MoarVM: Fix possible segfault on exit when using spesh log [08:40] ¦ MoarVM: [08:40] ¦ MoarVM: A normal exit without --full-cleanup did not stop the spesh thread. So spesh [08:40] ¦ MoarVM: may actually still be active and try to print things to the spesh log when [08:40] ¦ MoarVM: MVM_vm_exit closes the spesh log file handle. This would lead to a segfault in [08:40] ¦ MoarVM: vfprintf. Fix by stoping and joining the spesh thread even in MVM_vm_exit if [08:40] ¦ MoarVM: spesh logging is active. [08:40] ¦ MoarVM: [08:40] ¦ MoarVM: Fixes GH #1434 [08:40] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0fa3555648 [08:40] ¦ MoarVM: b77d328328 | niner++ (committed using GitHub Web editor) | src/moar.c [08:40] ¦ MoarVM: Merge pull request #1458 from MoarVM/fix_segfault_on_exit_with_spesh_log [08:40] ¦ MoarVM: [08:40] ¦ MoarVM: Fix possible segfault on exit when using spesh log [08:40] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b77d328328 [08:40] *** linkable6 left [08:43] *** linkable6 joined [08:56] *** frost-lab joined [09:30] * lizmat feels a bump is in the air [09:31] anybody against it? [09:33] how about i merge the decont PR first? [09:34] sure! [09:38] ¦ MoarVM: 9b94bab9eb | (Daniel Green)++ | src/core/interp.c [09:38] ¦ MoarVM: Always log the type coming out of an nqp::decont [09:38] ¦ MoarVM: [09:38] ¦ MoarVM: Before, it would only log if a decont was actually performed. That was [09:38] ¦ MoarVM: usually fine because most of the time there always was or wasn't a [09:38] ¦ MoarVM: container. If there was a container we logged the type, and if there [09:38] ¦ MoarVM: wasn't we usually could throw out the decont op altogether. However, in [09:38] ¦ MoarVM: the cases where there *was* a mix, the stats could be misleading. Given [09:38] ¦ MoarVM: <…commit message has 5 more lines…> [09:38] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9b94bab9eb [09:38] ¦ MoarVM: ba124ad128 | MasterDuke17++ (committed using GitHub Web editor) | src/core/interp.c [09:38] ¦ MoarVM: Merge pull request #1438 from MasterDuke17/always_log_type_in_decont [09:38] ¦ MoarVM: [09:38] ¦ MoarVM: Always log the type coming out of an nqp::decont [09:38] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ba124ad128 [09:38] are we ready to do the bump? [09:38] * lizmat cues disco music [09:38] should be [09:40] ok, working on it [09:58] bumped, including the NQP PR merge [09:58] * lizmat switches back to listening to XTC [10:03] * MasterDuke would que up some adam ant if i had any, just to be competative [10:10] .oO( Antmusic ) [10:16] the only thing i know about xtc and adam ant is from the TMBG song [10:18] * jnthn is currently listening to Turbulence (prog metal from Lebanon), which is pretty nice :) [10:18] hey jnthn, you have a message: https://gist.github.com/78c15c8e6a4f69516854612778fda397 [10:19] lol, "really soon" :P [10:19] I can't even remember what the multi refactor in question was [10:19] I am pretty sure there will be another multi refactor soon anyway though [10:19] Because new-disp [10:21] i'm on a minor kick of looking at the various XXXs in moarvm/nqp/rakudo to see if they're still relevant and can be fixed, or just removed [10:22] any thoughts about that one? [10:22] it's used here https://github.com/Raku/nqp/blame/master/src/NQP/Actions.nqp#L903 [10:24] I honestly can't remember :/ [10:25] jnthn: you qualify to be Dutch PM :-) [10:25] I'm guessing I was planning to change something about multi methods to look more like how Rakudo does it [10:26] lizmat: Better than qualifying to be Czech health minister; those seem to have a half life of six months... [10:26] ah, yes, the Dutch PM is now 3rd longest sitting PM [10:28] Maybe sitting around for so long is bad for memory? [10:29] "Functie elders" has been in the news a lot in NL, and the source of many jokes / memes [10:30] basically "Job elsewhere" [10:31] during preliminary negotiations for a new government, this leaked out as a talking point about the most active / prominent member of parliament [10:31] generally interpreted as "how do we defuse this guy" [10:32] our PM claimed to have "no active memory" of that discussion point [10:32] it leaked because of a picture of a pile of papers with that on top :-) [10:32] :D [10:49] there's a test failure in t/spec/S15-unicode-information/unimatch-general.t if run with MVM_SPESH_BLOCKING=1 [10:50] not ok 2 - ''.unimatch yields Nil [10:51] correction, it can fail even without MVM_SPESH_BLOCKING=1 [10:52] doesn't for me? [10:53] hmm, have you bumped your own machine? [10:53] that's where I pushed the bumps from :-) [10:53] odd [10:53] but /me is running on MacOS [10:54] yeah, i can repro [10:54] in any case, it fails for me reliably with MVM_SPESH_BLOCKING=1 [10:54] which I guess it shouldn't [10:56] to be fair, I have a few gc related setting changes on my system, that's might be why it fails even without the blocking flag set [10:56] interesting bit in that piece of code is, it returning Nil with a --> Bool:D signature [10:56] and the error value being False [10:57] m: dd Nil.Bool [10:57] rakudo-moar 726a75e24: OUTPUT: «Bool::False␤» [10:57] m: sub a(--> Bool:D) { Nil }; dd a [10:57] rakudo-moar 726a75e24: OUTPUT: «Nil␤» [10:57] perhaps that's a pointer ? [10:59] *** zakharyas left [11:02] the test that fails works fine from the command line `MVM_SPESH_BLOCKING=1 ./rakudo-m -I lib/ -e 'use Test; is unimatch("", "Nd"), Nil; is "".unimatch("Nd"), Nil'` [11:07] Interesting things happen if the last test becomes: is "".unimatch("Nd"), Nil for ^300 [11:11] dogbert17: .unimatch on an Int cannot return Nil [11:11] MasterDuke: run that code twice in the same process [11:11] and with MVM_SPESH_NODELAY=1 [11:13] nine dogbert17 Int.unimatch(..) can not return Nil [11:13] Str.unimatch(...) returns Nil only if the string is empty, so there's no codepoint to work on [11:29] *** MasterDuke left [11:29] *** MasterDuke joined [11:31] dogbert17: ha, always starts to succeed after 178 fails [11:33] so what is the test being done ? [11:38] MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -I lib/ -e 'use Test; is "".unimatch("Nd"), Nil for ^200' [11:40] doesn't start succeeding for me [11:40] starts failing for me at test #58 [12:08] *** frost-lab left [12:19] ¦ MoarVM: MasterDuke17++ created pull request #1464: Make smrt_intify specializable like other smrt_* ops [12:19] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1464 [12:20] MasterDuke: is that all that was needed ? [12:20] oh, completely unrelated [12:21] yeah, I realize that, but just setting a few flags seems like: not enough ? [12:23] just going by https://github.com/MasterDuke17/MoarVM/blob/smrt_intify_should_be_specializable/src/core/oplist#L55-L57 [12:40] lizmat: I merely wanted to show that the test behaviour changed depending on the amount of iterations [12:41] ah, ok :-) [12:43] all iterations succeed with MVM_SPESH_DISABLE=1, but fail with any of the specific disables (OSR, PEA, INLINE) [12:45] MasterDuke: have you tried turning off the jit? [12:46] all succeed [12:47] could try jit-bisecting it [13:00] *** zakharyas joined [14:13] huh, can't seem to get jit-bisect to work with this [14:27] *** patrickb left [17:17] *** domidumont left [17:26] MasterDuke: I tried spesh-bisect, it shows som numbers and stops at MVM_SPESH_LIMIT=49. What do I do with that information? [17:40] *** sena_kun left [17:41] *** sena_kun joined [17:52] dogbert17: there now should be a spesh-49.log or something like that [18:00] nine: can't find anything. Perhaps I should run with MVM_SPESH_LOG set? [18:01] tools/jit-bisect.pl already runs with MVM_SPESH_LOG [18:01] should be spesh-49.txt [18:01] It should also have said "SPESH Acquiring log: spesh-49.txt" [18:02] aha, but jit-bisect only says 'This program cannot be bisected: 256' [18:02] Oh, you tried spesh-bisect, not jit-bisect [18:03] I tried with MVM_SPESH_BLOCKING=1 nqp/MoarVM/tools/jit-bisect.pl ./perl6-m bug.pl6 [18:03] add --spesh [18:04] No need for MVM_SPESH_BLOCKING, the script adds that anyway [18:04] aha [18:04] it's looking more promising ... [18:05] SPESH Broken frame: 2688. [18:05] SPESH Acquiring log: spesh-2688.txt [18:05] ran it twice, same result [18:05] file is 35 kB [18:08] should I gist the entire file? [18:09] sure [18:11] https://gist.github.com/dogbert17/232897a9ab148783c20375ea2b84688d [18:20] *** sena_kun left [18:20] *** sena_kun joined [18:32] *** zakharyas left [18:38] Spesh of 'unimatch' (cuid: 18154, file: SETTING::src/core.c/unicodey.pm6:500) [18:38] certainly fits the problem [18:44] the problem being? returning Nil on a --> Bool:D sig ? [18:52] I think Nil is always allowed [18:52] m: sub foo(--> Bool:D) { Nil } ; dd foo [18:52] rakudo-moar 726a75e24: OUTPUT: «Nil␤» [18:55] yeah, but maybe something somewhere disagrees (sometimes) ? [18:55] and decides to coerce ? [18:55] m: dd Nil:Bool [18:55] rakudo-moar 726a75e24: OUTPUT: «5===SORRY!5=== Error while compiling ␤Invalid type smiley ':Bool' used, only ':D', ':U' and ':_' are allowed␤at :1␤------> 3dd Nil:Bool7⏏5␤ expecting any of:␤ pair value␤» [18:55] m: dd Nil.Bool [18:55] rakudo-moar 726a75e24: OUTPUT: «Bool::False␤» [19:21] *** patrickb joined [19:51] *** brrt joined [20:13] *** zakharyas joined [20:19] MVM_SPESH_BLOCKING=1 rakudo -e 'use nqp; sub foo(--> Bool:D) { nqp::iseq_i((my int $ord = nqp::ord("")), -1) ?? Nil !! True }; dd foo for ^200' [20:19] Changes its output from Nil to Bool::True after ~ 150 iterations [20:23] which sounds a bit buggy [20:24] bisectable6: use nqp; sub foo(--> Bool:D) { nqp::iseq_i((my int $ord = nqp::ord("")), -1) ?? Nil !! True }; my $a; $a := foo for ^2_000; say $a [20:24] MasterDuke, Will bisect the whole range automagically because no endpoints were provided, hang tight [20:25] MasterDuke, Output on all releases: https://gist.github.com/025603cb4d23030645bf290b5f0a6c0c [20:25] MasterDuke, More than 4 changes to bisect, please try a narrower range like old=2018.12 new=HEAD [20:25] evalable6: use nqp; sub foo(--> Bool:D) { nqp::iseq_i((my int $ord = nqp::ord("")), -1) ?? Nil !! True }; my $a; $a := foo for ^20_000; say $a [20:25] MasterDuke, rakudo-moar a26ff404f: OUTPUT: «True␤» [20:25] *** eater joined [20:26] Got it down to just: use nqp; sub foo() { nqp::ord("") == -1 ?? Nil !! True }; dd foo for ^200 [20:26] bisectable6: use nqp; sub foo(--> Bool:D) { nqp::iseq_i((my int $ord = nqp::ord("")), -1) ?? Nil !! True }; my $a; $a := foo for ^20_000; say $a [20:26] MasterDuke, Will bisect the whole range automagically because no endpoints were provided, hang tight [20:26] MasterDuke, Output on all releases: https://gist.github.com/6723a1c358858f7c24e1df871aa676fe [20:26] MasterDuke, More than 4 changes to bisect, please try a narrower range like old=2018.05 new=HEAD [20:26] *** eaterof left [20:27] bisectable6: old=2018.05 use nqp; sub foo(--> Bool:D) { nqp::iseq_i((my int $ord = nqp::ord("")), -1) ?? Nil !! True }; my $a; $a := foo for ^20_000; say $a [20:27] MasterDuke, Bisecting by output (old=2018.05 new=a26ff40) because on both starting points the exit code is 0 [20:27] <[Coke]> if someone has approved my PR, is it gauche to merge it myself? [20:28] MasterDuke, bisect log: https://gist.github.com/a5f8cd49b97fb1f7c320a6bffa818050 [20:28] MasterDuke, (2018-07-09) https://github.com/rakudo/rakudo/commit/bd0a1f8be0bb0c1f230bdf3eafefda6f154413dd [20:28] <[Coke]> (was just 1455, smol README updates) [20:30] [Coke]: yes [20:30] *** brrt left [20:31] ¦ MoarVM: 8a5e05b0ac | Coke++ | README.markdown [20:31] ¦ MoarVM: Minor README updates [20:31] ¦ MoarVM: [20:31] ¦ MoarVM: * cleanup old claims [20:31] ¦ MoarVM: * mention JS [20:31] ¦ MoarVM: * encourage IRC, not private email [20:31] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8a5e05b0ac [20:31] ¦ MoarVM: fb696f18aa | MasterDuke17++ (committed using GitHub Web editor) | README.markdown [20:31] ¦ MoarVM: Merge pull request #1455 from coke/master [20:31] ¦ MoarVM: [20:31] ¦ MoarVM: Minor README updates [20:31] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fb696f18aa [20:52] Actually, it's embarassingly short: use nqp; note nqp::ord("") for ^200' [20:52] Because it's actually a JIT bug [20:55] MVM_string_ord_at returns a MVMGrapheme32 which is a 32 bit signed integer. However we treat it as a 64 bit integer without proper sign extension, which turns a -1 into 4294967295 [20:56] Same bug is present in both the lego jit version (where I know how to fix it) and the expr jit version (where I don't) [20:56] *** linkable6 left [20:57] *** linkable6 joined [21:00] And now I do [21:02] *** zakharyas left [21:02] ¦ MoarVM/fix_ord_jit: 3a62bdf77a | (Stefan Seifert)++ | 2 files [21:02] ¦ MoarVM/fix_ord_jit: Fix JITed ordfirst/ordat/ordbaseat returning 4294967295 instead of -1 [21:02] ¦ MoarVM/fix_ord_jit: [21:02] ¦ MoarVM/fix_ord_jit: MVM_string_ord_at returns a MVMGrapheme32 which is a 32 bit signed integer. [21:02] ¦ MoarVM/fix_ord_jit: However we treated it as a 64 bit integer without proper sign extension, which [21:02] ¦ MoarVM/fix_ord_jit: turned a -1 into 4294967295. Fix by sign extend the result to a full 64 bit [21:02] ¦ MoarVM/fix_ord_jit: signed integer. [21:02] ¦ MoarVM/fix_ord_jit: review: https://github.com/MoarVM/MoarVM/commit/3a62bdf77a [21:02] ¦ MoarVM: niner++ created pull request #1465: Fix JITed ordfirst/ordat/ordbaseat returning 4294967295 instead of -1 [21:02] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1465 [21:12] *** patrickb left [21:22] <[Coke]> nine++ nice fix. [21:43] *** Kaiepi left [21:55] *** Geth left [21:56] *** Geth joined [21:58] *** sxmx left [22:03] *** sxmx joined