01:49 ilbot3 joined 05:30 brrt joined
brrt good * #moarvm 05:31
did we get to review TheLemonMans PR yet
guess not 05:32
okay, it looks good enough
going to run a test and then probably merge
dalek arVM/even-moar-jit: d99334c | brrt++ | docs/jit/register-allocator.org:
More notes on linear scan
 05:37
brrt hmmm 06:07
it looks and compiles correctly for sure
but i dunno what the 'actually thrown at' bit is about
dalek arVM: 8911949 | LemonBoy++ | src/core/ (3 files):
Remove keep_caller from MVMFrame

Fixes some cases (RT #128803) where the backtraces would be abruptly truncated due to an optimization introduced in cecf5729. As suggested by @jnthn [1] the best solution is to simply revert the optimization as it's not worth it anymore.
  [1] irclog.perlgeek.de/moarvm/2016-08-17#i_13040630		 06:26
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128803
06:27 brrt joined 06:38 TheLemonMan joined 06:50 travis-ci joined
travis-ci MoarVM build passed. LemonBoy 'Remove keep_caller from MVMFrame 06:50
travis-ci.org/MoarVM/MoarVM/builds/153478145 github.com/MoarVM/MoarVM/compare/0...1194990450
06:50 travis-ci left
TheLemonMan 'morning #moarvm! 07:03
07:13 lizmat joined 08:04 zakharyas joined
Zoffix TheLemonMan, would you add yourself to CREDITS, so you get creddited with proper name you want in the releases? github.com/rakudo/rakudo/blob/nom/CREDITS 10:09
TheLemonMan, we also have #perl6-dev if you were interesting in joining 10:26
TheLemonMan Zoffix, oh, I don't feel like I've contributed anything worthwile yet :)
Zoffix TheLemonMan, still :) The contributing script will pick up your commits and right now you show up as 'LemonBoy' :) 10:28
TheLemonMan so, it seems there's some unwanted sign-extension going on when accessing attributes with getattr_i even though the field's been marked with an unsigned native type 10:30
the NQP side specifies $MVM_reg_int64 as type of the result register and so does the getattr_i opcode 10:31
dalek arVM: fa43417 | LemonBoy++ | src/core/bytecodedump.c:
Correctly NULL-terminate the buffer in MVM_vm_dump_file.
 11:11
arVM: 31eccd7 | jnthn++ | src/core/bytecodedump.c:
Merge pull request #392 from LemonBoy/dump-trailing-null

Correctly NULL-terminate the buffer in MVM_vm_dump_file.
12:27 camelia joined 12:34 zakharyas1 joined 13:25 kjs_ joined 13:39 kjs_ joined 13:50 zakharyas joined
unmatched} I'm getting *** Error in `/home/cpan/CPANPRC/rakudo/install/bin/moar': double free or corruption (fasttop): 0x0000000005fc9430 ***" about 30% of the time when running S17-procasync/no-runaway-file-limit.t 14:14
And this likely was brought in (or got exposed by) in the today's nqp/moarvm bump, because I was stresstesting yesterday a lot and this failure never came up.
[Coke] Not many moarvm commits to test: -2016.07-17-g40948f6 14:15
+2016.07-24-g31eccd7
unmatched} doesn't know how to test 14:16
Do I just checkout a particular commit in nqp/MoarVM ? 14:17
in rakudo's repo
[Coke] pretty sure that if you do that, the nqp config will rebuild it with the "right" verison. 14:18
*verison
*VERSION
you can pass in specific versions with rakudo's Configure command, however.
nine You don't have to re-compile nqp and rakudo after changing moar
[Coke] perl Configure.pl --gen-nqp --gen-moar=sha1
nine: not always, but sometimes. 14:19
nine yes
[Coke] you could try that here, sure. build and install moarvm and retry?
(from your already checked out moar repo inside your rakudo checkout)
unmatched} will do 14:22
It's really flappy. Two runs dies right away, then many runs doesn't die: gist.github.com/zoffixznet/9ee7467...da33498099
nine Just for fun I ran a spectest without fudging. Let's say it's less than encouraging :P 14:42
unmatched} :(
nine On the bright side, it made me stumble across a hang: my $a = 10; $a[0] := 1 14:43
unmatched} The perl Configure.pl --gen-nqp --gen-moar=330b1b44ab07df548ca75bb61dc8c3d6b354b8ad didn't do anything it seels
*seems... It's probably just sees I'm using newer version or something, so it doesn't bother changing? 14:44
nine The hang has a rather trivial fix: github.com/rakudo/rakudo/commit/44...c76653fcc2
Oh, I'm in the wrong channel! 14:45
unmatched} "You asked me to build 330b1b44ab07df548ca75bb61dc8c3d6b354b8ad, but 2016.07-20-g330b1b4 is not new enough to satisfy version 2016.07-24-g31eccd7" 14:49
And if I just go in nqp/MoarVM, checkout, then perl Configure.pl; make; make install;, $*VM.version still gives me the wrong version. Is it meant to get updated? 15:00
timotimo TheLemonMan: i'd expect we want a getattr_u and/or setattr_u, though i'm not sure why sign-extension would happen with access 15:09
unless it's a shorter unsigned type, of course?
TheLemonMan timotimo, happens with u64 aswell 15:10
the code calls the get_int accessor, that's where I think the first extension happens 15:11
timotimo i think you might be a lot more knowledgable about this than me :) 15:12
if you're interested in adding a new op, start with src/core/oplist and use tools/update_ops.p6
TheLemonMan we could also repurpose getaddr_i by finding a way to check the destination register type 15:13
timotimo it'd have to be passed in by the caller, which would mean code-gen's got a say in this 15:17
alternatively, check the frame's static info's local types information blob from the interpreter or something
once we jit that, we'll constant fold that 15:18
(which we'll also have to do, of course)
GTG!
there's also a bug we have where ++ on a "small" int variable will lose the variable's smallness 15:55
TheLemonMan hmm, got an one-liner to show that ? 15:58
timotimo m: my int8 $foo = 127; $foo++; say $foo
camelia rakudo-moar dd5c28: OUTPUT«-128␤»
timotimo ... oh?
m: my uint8 $foo = 0; $foo--; say $foo
camelia rakudo-moar dd5c28: OUTPUT«-1␤»
timotimo there, unsignedness is what gets lost ... i guess?
TheLemonMan nice 15:59
timotimo we're not emitting the truncate (or what its name is) op after the ++ or --
16:11 lizmat joined
TheLemonMan m: sub prefix:<++>(int8:D $a is rw) { $a }; my int8 $foo = 127; say ++$foo; 16:35
camelia rakudo-moar dd5c28: OUTPUT«===SORRY!===␤At Frame 2, Instruction 9, op 'decont_i', operand 0, MAST::Local of wrong type (1) specified; expected 4␤»
unmatched} :o
timotimo hah 16:36
:D or :U don't make sense for int8 and other native types
because we don't have a way to signal undefined values
TheLemonMan yeah, it's a copy/paste leftover from the Int module 16:37
unmatched} Any idea how I can make rakudo use a different moarvm version? 16:38
timotimo sure 16:39
unmatched} If I do perl Configure.pl; make; make install in nqp/MoarVM that doesn't seem to be what ends up being used by ./perl6-m
timotimo my_moar_binary Perl6.moarvm ...
just cat perl6-m
unmatched} ah
timotimo++ thanks
uuhhh $ ./perl6-m -e 'say $*VM.version' ===SORRY!=== Method 'protect' not found for invocant of class 'Any' 16:41
TheLemonMan need to rebuild nqp with the other moarvm :P
timotimo mhm 16:42
well, a method on Any sounds more like something else is broken 16:43
er, i mean
it's clearly hoping to have a Lock somewhere where it gets an Any - perhaps an undefined value? - instead 16:44
unmatched} Screw it... The -Ofun is lost on me.
This is the modified version of the S17-procasync/no-runaway-file-limit.t test that seems to segfault more often than the original. If anyone else wants to chase the flapper. gist.github.com/zoffixznet/5654271...b44b8edab6 16:46
16:47 kjs_ joined
unmatched} Rakudobugged that flapper: rt.perl.org/Ticket/Display.html?id=128992 17:23
17:23 kjs_ joined
unmatched} Failing to reproduce it now, after nuking rakudo dir and building everything from scratch :/ I wonder if it went away or just hiding. 17:42
TheLemonMan ptpb.pw/fCRQ the decont_i is wrong as the opcode expects an i64 and finds an i8 17:44
m: sub way(int8 $a is rw) { $a = 3; }; my int8 $a = 0; way($a); say $a; 17:55
camelia rakudo-moar 079da9: OUTPUT«3␤»
unmatched} Well, I'm closing that ticket. For the past hour and 20m, I have been running that test in a loop in two terminals along with the entire stresstest in a loop, and none failed 18:37
So it may have been something unrelated to code :/
m: sub foo␤ #= some docs {}␤say &foo.WHY 19:24
camelia rakudo-moar 079da9: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Missing block␤at <tmp>:3␤------> sub foo⏏<EOL>␤ expecting any of:␤ new name to be defined␤»
unmatched} oops, wc
[Coke] ye?
unmatched} :| 19:40
pulled in rakudo changes and rebuilt again and booom.. the segfault is back. Happens quite regularly too :/
19:42 domidumont joined 19:48 domidumont joined 20:41 pyrimidine joined 22:56 lizmat joined 23:36 Zoffix 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!