Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-09-09

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:23 lizmat joined #moarvm
05:58 domidumont joined #moarvm
06:03 domidumont joined #moarvm
08:13 zakharyas joined #moarvm
09:14 domidumont joined #moarvm
09:27 brrt joined #moarvm
09:27 brrt hi #moarvm
09:27 brrt i figured out that negative synthetic nodes may not be as awesome an idea
09:28 brrt ... i have a somewhat, slightly better idea
09:28 brrt i add a 'SYNTH' as the zeroth node for any  jit tree, and refer to that instead
09:29 brrt that is a no-special-branch solution
09:29 brrt nwc10++ interesting talk on the non-butterfly effect
10:14 nwc10 Lee++ # bringing the tripod, camera and mike
11:16 ggoebel joined #moarvm
11:18 brrt yeah, having the videos online is really nice
11:18 nwc10 but we didn't promise anything in advance because
11:18 nwc10 1) we were not sure if it would work out
11:19 nwc10 2) we wanted folks who could to actually show up
11:19 nwc10 (someone had asked "will there be videos?" and the question appeared to be roughly "can I enjoy the conference from the comfort of the sofa and not have to interact with the nasty huuuumins"
11:19 nwc10 and if everyone stays at home, why have a conference?)
11:20 brrt yeah, i can see how that works
11:20 brrt for my part i had prefered to have been there, but $work...
11:21 * brrt has clearly gone over to the dark side
12:22 TheLemonMan joined #moarvm
12:23 TheLemonMan timotimo, turn MVM_GC_DEBUG_LOG_FLAGS on and enjoy the nice traces in gdb :D
12:23 TheLemonMan the STABLE object might get collected somewhere
14:34 TheLemonMan interesting, by enabling the debug output I get a crash while compiling rakudo, that's in process_worklist
14:34 TheLemonMan and it's actually a debug sentinel to catch null stables
14:38 TheLemonMan oh, in case you didn't know about rr (http://rr-project.org/), it's a nifty tool for the debugging lovers
14:42 brrt i did not know
14:51 timotimo i've heard of it, but i haevn't used it yet
15:03 MasterDuke_ joined #moarvm
15:04 MasterDuke_ ahoy #moarvm. just performing a driveby dropping of a bug report if anybody is interested
15:04 timotimo OK
15:04 MasterDuke_ RT #128035
15:04 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128035
15:05 MasterDuke_ i submitted a Rakudo PR https://github.com/rakudo/rakudo/pull/867/, but it turns out to be a MoarVM issue
15:09 MasterDuke_ just for the heck of it i tried changing the > on this line https://github.com/MoarVM/MoarVM/blob/94ed36d6b7c63a998d6849de5aa1330aaeea88ff/src/6model/reprs/P6bigint.c#L18 to a >=
15:10 MasterDuke_ and that fixed the problem in the original RT, but not surprisingly broke the nqp and rakudo spectests
15:11 MasterDuke_ and with that my work here is done, later all...
15:11 timotimo why would we be unable to unbox a 64bit big int?
15:12 MasterDuke_ (sucked back in) no idea
15:13 MasterDuke_ m: use nqp; say nqp::unbox_i(2**64); say nqp::unbox_i(2**64 - 1)
15:13 camelia rakudo-moar c9b18c: OUTPUT«Cannot unbox 65 bit wide bigint into native integer␤  in block <unit> at <tmp> line 1␤␤»
15:13 MasterDuke_ m: use nqp; say nqp::unbox_i(2**64 - 1);
15:13 camelia rakudo-moar c9b18c: OUTPUT«-1␤»
15:14 timotimo that seems legit
15:14 MasterDuke_ m: use nqp; say nqp::unbox_i(2**63);
15:14 camelia rakudo-moar c9b18c: OUTPUT«-9223372036854775808␤»
15:14 MasterDuke_ m: use nqp; say nqp::unbox_i(2**63 - 1);
15:14 camelia rakudo-moar c9b18c: OUTPUT«9223372036854775807␤»
15:15 MasterDuke_ m: say int.Range.max
15:15 camelia rakudo-moar c9b18c: OUTPUT«9223372036854775807␤»
15:15 MasterDuke_ m: say uint.Range.max
15:15 camelia rakudo-moar c9b18c: OUTPUT«18446744073709551615␤»
15:15 timotimo hmm
15:20 MasterDuke_ i'm a little unclear why the funtion's name is mp_get_int64, but it returns a MVMuint64 instead of a MVMint64
15:20 TheLemonMan you should just check https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/P6bigint.c#L102 in the if arm whether the sign-extended version becomes negative
15:21 TheLemonMan or simply check if you're going to set the MSB when assembling the result
15:23 timotimo MasterDuke_: maybe because the sign is a separate bit in the mp library we use? no clue.
15:23 MasterDuke_ (this reminds me of physics tests where i'd get something like g = -9.8m/s**2, which i always tried to argue was a fine answer)
15:24 TheLemonMan you can easily test this by checking out the result of (int64_t)(1ULL << 63)
15:26 MasterDuke_ well, i really do need to run now, but i'll play around with your suggestions this evening if nobody else get a fix in before then
15:26 MasterDuke_ thanks all
15:27 TheLemonMan and MP_LT == mp_cmp_d(i, 0) can be optimized out with SIGN(i) if I understand the code correctly
15:29 timotimo oh, that sounds sensible
15:50 TheLemonMan done o/
15:54 TheLemonMan the mp_neg(i,i) calls can also be thrown away by using SIGN(i) ^= 1
15:54 TheLemonMan or SIGN(i) ^= MP_NEG to be fancy heh
16:02 timotimo most stuff we do is non-destructive
16:39 domidumont joined #moarvm
16:55 domidumont joined #moarvm
17:29 FROGGS joined #moarvm
18:02 pyrimidine joined #moarvm
18:16 lizmat joined #moarvm
18:22 TheLemonMan joined #moarvm
22:54 Ven_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary