github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:17 Kaiepi left, Kaiepi joined, vrurg joined 00:22 vrurg left 00:54 vrurg joined, vrurg left, vrurg joined 02:23 bisectable6 left, statisfiable6 left, greppable6 left, tellable6 left, benchable6 left, unicodable6 left, linkable6 left, evalable6 left, releasable6 left, quotable6 left, coverable6 left, notable6 left, sourceable6 left, bloatable6 left, shareable6 left, nativecallable6 left, committable6 left, squashable6 left 02:24 greppable6 joined, linkable6 joined, quotable6 joined, benchable6 joined, squashable6 joined, sourceable6 joined 02:25 committable6 joined, evalable6 joined, bisectable6 joined, notable6 joined, statisfiable6 joined, unicodable6 joined 02:26 shareable6 joined, coverable6 joined, tellable6 joined, bloatable6 joined, releasable6 joined, nativecallable6 joined 03:50 sxmx left 06:52 domidumont joined 06:57 patrickb joined, sxmx joined
Geth MoarVM/master: 4 commits pushed by (Salvador Ortiz)++, MasterDuke17++ 07:43
MoarVM: 726447d71a | (Salvador Ortiz)++ | src/6model/reprs/VMArray.c
VMArray: Check slot type for read_buf and write_buf

Those operations are only valid when the array_type is of some integer kind.
Should closes #1310
MoarVM: c49482208e | MasterDuke17++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
Merge pull request #1440 from salortiz/array-check-slot

VMArray: Check slot type for read_buf and write_buf
07:43 linkable6 left 07:45 linkable6 joined 07:48 zakharyas joined
Geth MoarVM: 0fa3555648 | (Stefan Seifert)++ | src/moar.c
Fix possible segfault on exit when using spesh log

A normal exit without --full-cleanup did not stop the spesh thread. So spesh may actually still be active and try to print things to the spesh log when MVM_vm_exit closes the spesh log file handle. This would lead to a segfault in vfprintf. Fix by stoping and joining the spesh thread even in MVM_vm_exit if spesh logging is active.
Fixes GH #1434		 08:40
MoarVM: b77d328328 | niner++ (committed using GitHub Web editor) | src/moar.c
Merge pull request #1458 from MoarVM/fix_segfault_on_exit_with_spesh_log

Fix possible segfault on exit when using spesh log
08:40 linkable6 left 08:43 linkable6 joined 08:56 frost-lab joined
lizmat feels a bump is in the air 09:30
anybody against it? 09:31
MasterDuke how about i merge the decont PR first? 09:33
lizmat sure! 09:34
Geth MoarVM: 9b94bab9eb | (Daniel Green)++ | src/core/interp.c
Always log the type coming out of an nqp::decont

Before, it would only log if a decont was actually performed. That was usually fine because most of the time there always was or wasn't a container. If there was a container we logged the type, and if there wasn't we usually could throw out the decont op altogether. However, in the cases where there *was* a mix, the stats could be misleading. Given ... (5 more lines)		 09:38
MoarVM: ba124ad128 | MasterDuke17++ (committed using GitHub Web editor) | src/core/interp.c
Merge pull request #1438 from MasterDuke17/always_log_type_in_decont

Always log the type coming out of an nqp::decont
lizmat are we ready to do the bump?
lizmat cues disco music
MasterDuke should be
lizmat ok, working on it 09:40
bumped, including the NQP PR merge 09:58
lizmat switches back to listening to XTC
MasterDuke would que up some adam ant if i had any, just to be competative 10:03
lizmat
.oO( Antmusic )
 10:10
MasterDuke the only thing i know about xtc and adam ant is from the TMBG song 10:16
jnthn is currently listening to Turbulence (prog metal from Lebanon), which is pretty nice :) 10:18
tellable6 hey jnthn, you have a message: gist.github.com/78c15c8e6a4f695168...2778fda397
jnthn lol, "really soon" :P 10:19
I can't even remember what the multi refactor in question was
I am pretty sure there will be another multi refactor soon anyway though
Because new-disp
MasterDuke 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:21
any thoughts about that one? 10:22
it's used here github.com/Raku/nqp/blame/master/s...s.nqp#L903
jnthn I honestly can't remember :/ 10:24
lizmat jnthn: you qualify to be Dutch PM :-) 10:25
jnthn I'm guessing I was planning to change something about multi methods to look more like how Rakudo does it
lizmat: Better than qualifying to be Czech health minister; those seem to have a half life of six months... 10:26
lizmat ah, yes, the Dutch PM is now 3rd longest sitting PM
jnthn Maybe sitting around for so long is bad for memory? 10:28
lizmat "Functie elders" has been in the news a lot in NL, and the source of many jokes / memes 10:29
basically "Job elsewhere" 10:30
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"
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 :-)
jnthn :D
dogbert17 there's a test failure in t/spec/S15-unicode-information/unimatch-general.t if run with MVM_SPESH_BLOCKING=1 10:49
not ok 2 - ''.unimatch yields Nil 10:50
correction, it can fail even without MVM_SPESH_BLOCKING=1 10:51
lizmat doesn't for me? 10:52
dogbert17 hmm, have you bumped your own machine? 10:53
lizmat that's where I pushed the bumps from :-)
dogbert17 odd
lizmat but /me is running on MacOS
MasterDuke yeah, i can repro 10:54
lizmat in any case, it fails for me reliably with MVM_SPESH_BLOCKING=1
dogbert17 which I guess it shouldn't
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
lizmat interesting bit in that piece of code is, it returning Nil with a --> Bool:D signature
and the error value being False
m: dd Nil.Bool 10:57
camelia Bool::False
lizmat m: sub a(--> Bool:D) { Nil }; dd a
camelia Nil
lizmat perhaps that's a pointer ?
10:59 zakharyas left
MasterDuke 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:02
dogbert17 Interesting things happen if the last test becomes: is "".unimatch("Nd"), Nil for ^300 11:07
lizmat dogbert17: .unimatch on an Int cannot return Nil 11:11
nine MasterDuke: run that code twice in the same process
and with MVM_SPESH_NODELAY=1
lizmat 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, MasterDuke joined
MasterDuke dogbert17: ha, always starts to succeed after 178 fails 11:31
lizmat so what is the test being done ? 11:33
MasterDuke MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -I lib/ -e 'use Test; is "".unimatch("Nd"), Nil for ^200' 11:38
lizmat doesn't start succeeding for me 11:40
starts failing for me at test #58
12:08 frost-lab left
Geth MoarVM: MasterDuke17++ created pull request #1464:
Make smrt_intify specializable like other smrt_* ops		 12:19
lizmat MasterDuke: is that all that was needed ? 12:20
MasterDuke oh, completely unrelated
lizmat yeah, I realize that, but just setting a few flags seems like: not enough ? 12:21
MasterDuke just going by github.com/MasterDuke17/MoarVM/blo...st#L55-L57 12:23
dogbert17 lizmat: I merely wanted to show that the test behaviour changed depending on the amount of iterations 12:40
lizmat ah, ok :-) 12:41
MasterDuke all iterations succeed with MVM_SPESH_DISABLE=1, but fail with any of the specific disables (OSR, PEA, INLINE) 12:43
dogbert17 MasterDuke: have you tried turning off the jit? 12:45
MasterDuke all succeed 12:46
could try jit-bisecting it 12:47
13:00 zakharyas joined
MasterDuke huh, can't seem to get jit-bisect to work with this 14:13
14:27 patrickb left 17:17 domidumont left
dogbert17 MasterDuke: I tried spesh-bisect, it shows som numbers and stops at MVM_SPESH_LIMIT=49. What do I do with that information? 17:26
17:40 sena_kun left 17:41 sena_kun joined
nine dogbert17: there now should be a spesh-49.log or something like that 17:52
dogbert17 nine: can't find anything. Perhaps I should run with MVM_SPESH_LOG set? 18:00
nine tools/jit-bisect.pl already runs with MVM_SPESH_LOG 18:01
should be spesh-49.txt
It should also have said "SPESH Acquiring log: spesh-49.txt"
dogbert17 aha, but jit-bisect only says 'This program cannot be bisected: 256' 18:02
nine Oh, you tried spesh-bisect, not jit-bisect
dogbert17 I tried with MVM_SPESH_BLOCKING=1 nqp/MoarVM/tools/jit-bisect.pl ./perl6-m bug.pl6 18:03
nine add --spesh
No need for MVM_SPESH_BLOCKING, the script adds that anyway 18:04
dogbert17 aha
it's looking more promising ...
SPESH Broken frame: 2688. 18:05
SPESH Acquiring log: spesh-2688.txt
ran it twice, same result
file is 35 kB
should I gist the entire file? 18:08
nine sure 18:09
dogbert17 gist.github.com/dogbert17/232897a9...ea2b84688d 18:11
18:20 sena_kun left, sena_kun joined 18:32 zakharyas left
nine Spesh of 'unimatch' (cuid: 18154, file: SETTING::src/core.c/unicodey.pm6:500) 18:38
certainly fits the problem
lizmat the problem being? returning Nil on a --> Bool:D sig ? 18:44
nine I think Nil is always allowed 18:52
m: sub foo(--> Bool:D) { Nil } ; dd foo
camelia Nil
lizmat yeah, but maybe something somewhere disagrees (sometimes) ? 18:55
and decides to coerce ?
m: dd Nil:Bool
camelia 5===SORRY!5=== Error while compiling <tmp>
Invalid type smiley ':Bool' used, only ':D', ':U' and ':_' are allowed
at <tmp>:1
------> 3dd Nil:Bool7ā5<EOL>
expecting any of:
pair value
lizmat m: dd Nil.Bool
camelia Bool::False
19:21 patrickb joined 19:51 brrt joined 20:13 zakharyas joined
nine 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
dogbert17 which sounds a bit buggy 20:23
MasterDuke 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
bisectable6 MasterDuke, Will bisect the whole range automagically because no endpoints were provided, hang tight
MasterDuke, Output on all releases: gist.github.com/025603cb4d23030645...0b5f0a6c0c 20:25
MasterDuke, More than 4 changes to bisect, please try a narrower range like old=2018.12 new=HEAD
MasterDuke 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
evalable6 True
20:25 eater joined
nine Got it down to just: use nqp; sub foo() { nqp::ord("") == -1 ?? Nil !! True }; dd foo for ^200 20:26
MasterDuke 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
bisectable6 MasterDuke, Will bisect the whole range automagically because no endpoints were provided, hang tight
MasterDuke, Output on all releases: gist.github.com/6723a1c358858f7c24...871aa676fe
MasterDuke, More than 4 changes to bisect, please try a narrower range like old=2018.05 new=HEAD
20:26 eaterof left
MasterDuke 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
bisectable6 MasterDuke, Bisecting by output (old=2018.05 new=a26ff40) because on both starting points the exit code is 0
[Coke] if someone has approved my PR, is it gauche to merge it myself?
bisectable6 MasterDuke, bisect log: gist.github.com/a5f8cd49b97fb1f7c3...bffa818050 20:28
MasterDuke, (2018-07-09) github.com/rakudo/rakudo/commit/bd...6f154413dd
[Coke] (was just 1455, smol README updates)
nine [Coke]: yes 20:30
20:30 brrt left
Geth MoarVM: 8a5e05b0ac | Coke++ | README.markdown
Minor README updates

  * cleanup old claims
  * mention JS
  * encourage IRC, not private email		 20:31
MoarVM: fb696f18aa | MasterDuke17++ (committed using GitHub Web editor) | README.markdown
Merge pull request #1455 from coke/master

Minor README updates
nine Actually, it's embarassingly short: use nqp; note nqp::ord("") for ^200' 20:52
Because it's actually a JIT bug
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:55
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
20:56 linkable6 left 20:57 linkable6 joined
nine And now I do 21:00
21:02 zakharyas left
Geth MoarVM/fix_ord_jit: 3a62bdf77a | (Stefan Seifert)++ | 2 files
Fix JITed ordfirst/ordat/ordbaseat returning 4294967295 instead of -1

MVM_string_ord_at returns a MVMGrapheme32 which is a 32 bit signed integer. However we treated it as a 64 bit integer without proper sign extension, which turned a -1 into 4294967295. Fix by sign extend the result to a full 64 bit signed integer.		 21:02
MoarVM: niner++ created pull request #1465:
Fix JITed ordfirst/ordat/ordbaseat returning 4294967295 instead of -1
21:12 patrickb left
[Coke] nine++ nice fix. 21:22
21:43 Kaiepi left 21:55 Geth left 21:56 Geth joined 21:58 sxmx left 22:03 sxmx 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!