01:48
ilbot3 joined
02:23
lizmat joined
05:58
domidumont joined
06:03
domidumont joined
08:13
zakharyas joined
09:14
domidumont joined
09:27
brrt joined
|
|||
brrt | hi #moarvm | 09:27 | |
i figured out that negative synthetic nodes may not be as awesome an idea | |||
... i have a somewhat, slightly better idea | 09:28 | ||
i add a 'SYNTH' as the zeroth node for any jit tree, and refer to that instead | |||
that is a no-special-branch solution | 09:29 | ||
nwc10++ interesting talk on the non-butterfly effect | |||
nwc10 | Lee++ # bringing the tripod, camera and mike | 10:14 | |
11:16
ggoebel joined
|
|||
brrt | yeah, having the videos online is really nice | 11:18 | |
nwc10 | but we didn't promise anything in advance because | ||
1) we were not sure if it would work out | |||
2) we wanted folks who could to actually show up | 11:19 | ||
(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" | |||
and if everyone stays at home, why have a conference?) | |||
brrt | yeah, i can see how that works | 11:20 | |
for my part i had prefered to have been there, but $work... | |||
brrt has clearly gone over to the dark side | 11:21 | ||
12:22
TheLemonMan joined
|
|||
TheLemonMan | timotimo, turn MVM_GC_DEBUG_LOG_FLAGS on and enjoy the nice traces in gdb :D | 12:23 | |
the STABLE object might get collected somewhere | |||
interesting, by enabling the debug output I get a crash while compiling rakudo, that's in process_worklist | 14:34 | ||
and it's actually a debug sentinel to catch null stables | |||
oh, in case you didn't know about rr (rr-project.org/), it's a nifty tool for the debugging lovers | 14:38 | ||
brrt | i did not know | 14:42 | |
timotimo | i've heard of it, but i haevn't used it yet | 14:51 | |
15:03
MasterDuke_ joined
|
|||
MasterDuke_ | ahoy #moarvm. just performing a driveby dropping of a bug report if anybody is interested | 15:04 | |
timotimo | OK | ||
MasterDuke_ | RT #128035 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128035 | ||
MasterDuke_ | i submitted a Rakudo PR github.com/rakudo/rakudo/pull/867/, but it turns out to be a MoarVM issue | 15:05 | |
just for the heck of it i tried changing the > on this line github.com/MoarVM/MoarVM/blob/94ed...gint.c#L18 to a >= | 15:09 | ||
and that fixed the problem in the original RT, but not surprisingly broke the nqp and rakudo spectests | 15:10 | ||
and with that my work here is done, later all... | 15:11 | ||
timotimo | why would we be unable to unbox a 64bit big int? | ||
MasterDuke_ | (sucked back in) no idea | 15:12 | |
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» | ||
MasterDuke_ | m: use nqp; say nqp::unbox_i(2**64 - 1); | ||
camelia | rakudo-moar c9b18c: OUTPUT«-1» | ||
timotimo | that seems legit | 15:14 | |
MasterDuke_ | m: use nqp; say nqp::unbox_i(2**63); | ||
camelia | rakudo-moar c9b18c: OUTPUT«-9223372036854775808» | ||
MasterDuke_ | m: use nqp; say nqp::unbox_i(2**63 - 1); | ||
camelia | rakudo-moar c9b18c: OUTPUT«9223372036854775807» | ||
MasterDuke_ | m: say int.Range.max | 15:15 | |
camelia | rakudo-moar c9b18c: OUTPUT«9223372036854775807» | ||
MasterDuke_ | m: say uint.Range.max | ||
camelia | rakudo-moar c9b18c: OUTPUT«18446744073709551615» | ||
timotimo | hmm | ||
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 github.com/MoarVM/MoarVM/blob/mast...int.c#L102 in the if arm whether the sign-extended version becomes negative | ||
or simply check if you're going to set the MSB when assembling the result | 15:21 | ||
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) | ||
TheLemonMan | you can easily test this by checking out the result of (int64_t)(1ULL << 63) | 15:24 | |
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 | |
thanks all | |||
TheLemonMan | and MP_LT == mp_cmp_d(i, 0) can be optimized out with SIGN(i) if I understand the code correctly | 15:27 | |
timotimo | oh, that sounds sensible | 15:29 | |
TheLemonMan | done o/ | 15:50 | |
the mp_neg(i,i) calls can also be thrown away by using SIGN(i) ^= 1 | 15:54 | ||
or SIGN(i) ^= MP_NEG to be fancy heh | |||
timotimo | most stuff we do is non-destructive | 16:02 | |
16:39
domidumont joined
16:55
domidumont joined
17:29
FROGGS joined
18:02
pyrimidine joined
18:16
lizmat joined
18:22
TheLemonMan joined
22:54
Ven_ joined
|