|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:25
leont left
00:32
MasterDuke left
04:43
Kaiepi left
05:10
Altai-man joined
05:42
sena_kun joined
05:44
Altai-man left
|
|||
| nwc10 | good *, #moarvm | 06:05 | |
|
06:56
domidumont joined
07:30
MasterDuke joined
07:35
zakharyas joined
08:21
leont joined
|
|||
| MasterDuke | m: use nqp; say nqp::rand_I(4, Int); say nqp::rand_I(-4, Int) | 09:13 | |
| camelia | 2 -3903224497161057762 |
||
| MasterDuke | is ^^^ what we want for a negative max? | 09:14 | |
| m: use nqp; say nqp::rand_I(4, Int); say nqp::rand_I(-4, Int); say nqp::rand_n(-4.Num) | 09:22 | ||
| camelia | 0 -3012288344253263843 -2.5339036164595212 |
||
| MasterDuke | or is ^^^ what we want for the *_I version also? | ||
| m: say -19.rand.Int | 09:23 | ||
| camelia | -4 | ||
| MasterDuke | nothing in nqp or rakudo actually calls rand_I with a negative number. the only times it's used it's called with the $!elems of a Range | 09:25 | |
|
09:41
Altai-man joined
|
|||
| MasterDuke | there are no tests for behavior with a negative number, so i propose changing it to do what rand_n does (i.e., generate a number in the range -N < x <= 0) | 09:43 | |
|
09:44
sena_kun left
10:03
lizmat_ joined
10:05
lizmat left
10:06
lizmat_ is now known as lizmat
10:07
sena_kun joined
10:09
Altai-man left
11:25
zakharyas left
|
|||
| MasterDuke | hm. is it safe to put a `char *` that's been alloca'ed in an MVM_exception_throw_adhoc? | 12:11 | |
| nwc10 | er, I guess not. Because the allocation is on the stack and the stack gets unwound as a side effect of throwing the exception | 12:12 | |
| "what does valgrind say?" :-) | |||
|
12:30
Geth left,
Geth joined
12:38
zakharyas joined
12:43
zakharyas1 joined
12:44
zakharyas2 joined
12:45
zakharyas left
12:47
zakharyas1 left
13:41
Altai-man joined
13:44
sena_kun left
15:12
domidumont left
|
|||
| MasterDuke | timotimo: didn't you do some optimization recently re de-virtualizing get_boxed_ref()? could anything be done here github.com/MoarVM/MoarVM/blob/mast....c#L74-L83 ? | 15:50 | |
| i think this branch is almost ready to PR. it fails one spectest (doesn't die on a large exponentiation because gmp can handle the value), but i'm willing to argue the test can be changed | 16:16 | ||
| however, there are two things still to address: | |||
| 1) i still haven't been able to get it to link against the .a and unless i LD_PRELOAD the .so that does get built it picks up the system gmp | 16:18 | ||
| 2) i'm catching abort() with a signal handler and setjmp/longjmp (only for exponentiation right now), but i think it's fragile. i see more random fails in spectest runs than usual. do we go ahead with the code as is, assuming that the vast majority of user code isn't actually likely to cause aborts? or is there a way to make this robust without | 16:25 | ||
| patching gmp? or do we need to patch and hope the change can be pushed+accepted upstream? | |||
|
17:26
zakharyas2 left
|
|||
| timotimo | MasterDuke: i do believe we have a special op that grabs the bigint part from an object that spesh emits | 17:35 | |
|
17:42
sena_kun joined
17:44
Altai-man left
|
|||
| MasterDuke | ah, so we don't need to do anything there because spesh optimizes it for us later? | 17:52 | |
| timotimo | as long as it's not called directly from C code | 17:53 | |
| MasterDuke | ah. so all the calls directly in bigintops.c are unoptimized? anything that can be done with them? | 17:57 | |
| timotimo | check the optimized sp_ ops in interp.c | 18:16 | |
| like sp_add_I | 18:17 | ||
|
18:25
zakharyas joined
18:47
vrurg left
18:48
vrurg joined
|
|||
| MasterDuke | i just wondered if an sp_pow_I would make sense, but MVM_bigint_pow is only called 19 times when compiling core.c | 19:12 | |
| twice with a base of 10 and exponent of 307, seems a pretty large number | 19:13 | ||
| lizmat | and yet another Rakudo Weekly hits the Net: rakudoweekly.blog/2020/10/12/2020-...irst-year/ | 19:14 | |
|
19:17
sena_kun left
|
|||
| timotimo | 307, don't i know that number from floating point numbres? | 19:17 | |
| MasterDuke | is there a good way to find the file/line currently being compiled? i'm in gdb, but MVM_dump_backtrace(tc) just shows me in infix:<**> to no surprise | 19:18 | |
| ah | 19:19 | ||
| timotimo | is that in the optimizer per chance? | 19:20 | |
| MasterDuke | github.com/rakudo/rakudo/blob/mast...l.pm6#L194 | ||
| dogbert17 | perhaps 307 has something to do with double floating point numbers | 19:35 | |
| nwc10 | 10e308 | 19:50 | |
| dogbert17 | close :) | 20:11 | |
| MasterDuke | oh, should link my changes. these commits haven't been fully cleaned up, but the final diff should be pretty close github.com/MoarVM/MoarVM/compare/m...8e807R1094 | 20:21 | |
|
20:31
Geth left
20:56
zakharyas left
|
|||