github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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 ?
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
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
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
MasterDuke huh, can't seem to get jit-bisect to work with this 14:13
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
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
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
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
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
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
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
nine And now I do 21:00
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
[Coke] nine++ nice fix. 21:22

Powered by Cro and the Raku® Programming Language.

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

Thank you!