[05:56] good *, #moarvm [05:58] MasterDuke: thanks. In this case cppcheck is not correct [05:58] and it's arguably a bit silly, as I didn't write sizeof(entry_raw) [05:58] I wrote sizeof() with a type [05:59] and a type which is not the type of cntry_raw [07:25] *** brrt joined [07:36] good *, brrt [07:38] good * nwc10 :-) [07:39] another slog waiting for us [07:39] slog? Something specific, or simply "Tuesday" ? [07:40] I guess 'tuesday' [07:42] *** leont joined [07:44] *** zakharyas joined [07:57] nwc10: cool. i'll admit i didn't bother checking the checker and just passed on its warning [07:57] I'm assuming that that was the only thing in the hash code that it grumbled about. If so, that's good [07:58] iirc, yes [07:58] and there *might* still be buffer overflows. But all the regression tests pass under ASAN (and I wrote some more tests) so there aren't any *obvious* ones. [08:01] *** domidumont joined [08:25] wow. gmp really is quite a bit faster. `my ($a; $b; $c; $s); for 66..5_000 -> $e { $a = 23**$e; $b = 7**$e; $c = $a % $b; $c *= $c; $c += $a; $c -= $b; $s = ~$c }; say $s.substr(0, 10); say now - INIT now` takes about 35s with libtommath. on my gmp branch it takes 0.24s (and gives the same result) [08:30] wow [08:30] is it the stringifcation that is slow in libtommath, or everything? [08:32] well, the stringification is *really* slow. but so far everything i've tested is slower to some degree [08:33] the difference is way less dramatic if i take out the stringification every loop [08:35] if i increase the range to 10_000, but don't stringify every iteration, libtommath is ~2.1s and gmp is ~0.36s [08:37] the stringification is definitely an algorithmic difference. my pure-Raku implementation of stringification using Barrett reduction was faster than libtomath at ~2**600 iirc [08:38] and i haven't yet gotten around to finalizing my implementation for libtommath... [08:46] *** domidumont left [09:30] *** harrow` left [09:32] *** harrow joined [09:36] *** domidumont joined [09:43] *** brrt left [10:09] *** brrt joined [11:16] *** brrt left [11:19] *** MasterDuke left [11:32] *** zakharyas left [11:39] *** MasterDuke joined [11:47] ¦ MoarVM: 0015fd05bd | (Nicholas Clark)++ | 3 files [11:47] ¦ MoarVM: Re-instate meaningful hash iterator debugging inside HASH_DEBUG_ITER. [11:47] ¦ MoarVM: [11:47] ¦ MoarVM: The previous debugging code was removed as part of commit bac1ae1cf74f2917: [11:47] ¦ MoarVM: Re-implement MVMStrHashTable as a Robin Hood Hash. [11:47] ¦ MoarVM: [11:47] ¦ MoarVM: and never added back. [11:47] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0015fd05bd [11:47] ¦ MoarVM: fb99295086 | (Nicholas Clark)++ | 4 files [11:47] ¦ MoarVM: Add MVM_str_hash_iterator_target_deleted() for HASH_DEBUG_ITER. [11:47] ¦ MoarVM: [11:47] ¦ MoarVM: This name is rather a mouthful, but it describes the logic that this [11:47] ¦ MoarVM: function encapsulates - does this hash iterator point to an entry that has [11:47] ¦ MoarVM: been deleted. This avoids repeating implementation details in four places. [11:47] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fb99295086 [12:21] *** MasterDuke left [12:38] *** pamplemousse__ joined [12:48] *** sena_kun joined [12:54] *** zakharyas joined [13:07] *** squashable6 left [13:08] *** squashable6 joined [13:10] *** MasterDuke joined [13:56] ¦ MoarVM: 60070970c4 | (Nicholas Clark)++ | src/core/fixedsizealloc.c [13:56] ¦ MoarVM: oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [13:56] ¦ MoarVM: [13:56] ¦ MoarVM: Previously this wasn't trapped. With FSA_SIZE_DEBUG enabled (not the default) [13:56] ¦ MoarVM: everything works (it can allocate "0" bytes, as it adds its debugging record [13:56] ¦ MoarVM: keeping to the size requested). With default settings, we corrupt the malloc [13:56] ¦ MoarVM: heap, which doesn't get reported at the time, and may or may not get reported [13:56] ¦ MoarVM: in any useful way later. [13:56] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/60070970c4 [14:15] *** travis-ci joined [14:15] MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [14:15] https://travis-ci.org/MoarVM/MoarVM/builds/731288125 https://github.com/MoarVM/MoarVM/compare/fb9929508665...60070970c4a7 [14:15] *** travis-ci left [14:19] dear travis dry-by bot - *what* failed? [14:20] dry-by, eh? [14:20] er, drive-by [14:21] <[Coke]> looks like only some of the builds failed. one error is Error: retrieving gpg key timed out. [14:21] ah, ugh [14:21] one of our bots used to check what killed a travis build [14:21] ah, I missed that it splats 2 URLs [14:21] i think it was one run by zoffix that hasn't been put back online by anybody else since he left [14:21] <[Coke]> I think someone with privs could re-start that job and hope it didn't time out this time [14:22] <[Coke]> I can see the error, but don't see a "re-run" anywhere on the sub jobs. [14:22] let me have a look [14:22] how good that it has a button directly on that list, makes it faster to restart many jobs in a row [14:27] jobs still failing with the same error [14:27] one of the restarted jobs seems to succeed now [14:41] *** travis-ci joined [14:41] MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [14:41] https://travis-ci.org/MoarVM/MoarVM/builds/731288125 https://github.com/MoarVM/MoarVM/compare/fb9929508665...60070970c4a7 [14:41] *** travis-ci left [14:42] Those logs are not cool. [14:46] If those are internal travis issues, if its coverage is done by azure, maybe we can deprecate-disable travis? Azure builds go just fine. [14:48] *** travis-ci joined [14:48] MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [14:48] https://travis-ci.org/MoarVM/MoarVM/builds/731288125 https://github.com/MoarVM/MoarVM/compare/fb9929508665...60070970c4a7 [14:48] *** travis-ci left [14:56] *** Altai-man joined [14:58] *** sena_kun left [15:43] *** zakharyas left [15:48] *** zakharyas joined [16:24] *** elcaro left [16:31] *** elcaro joined [16:36] *** elcaro left [16:37] *** elcaro joined [16:37] *** domidumont left [16:44] *** elcaro left [16:44] *** elcaro joined [17:28] *** pamplemousse__ left [17:28] *** zakharyas left [17:30] *** elcaro left [17:37] *** elcaro joined [17:38] *** chansen_ left [17:38] *** kawaii left [17:39] *** tbrowder left [17:41] ¦ MoarVM/hash-single-allocation: 20 commits pushed by (Nicholas Clark)++ [17:41] ¦ MoarVM/hash-single-allocation: review: https://github.com/MoarVM/MoarVM/compare/cd8c07baf825...7af3353ace9f [17:54] *** kawaii joined [17:58] *** tbrowder joined [18:00] *** chansen_ joined [18:05] *** pamplemousse__ joined [18:31] *** pamplemousse__ left [18:56] *** sena_kun joined [18:56] oops, try this one [18:57] ¦ MoarVM/hash-single-allocation: 17 commits pushed by (Nicholas Clark)++ [18:57] ¦ MoarVM/hash-single-allocation: review: https://github.com/MoarVM/MoarVM/compare/7af3353ace9f...0d978ba231a9 [18:58] *** Altai-man left [19:06] *** elcaro left [19:06] *** kawaii left [19:07] *** kawaii joined [19:23] *** elcaro joined [19:26] WTF - I think tha this thing is working first time. [19:26] (OK, one typo before it would compile) [19:26] it compiles - ship it! [19:39] *** zakharyas joined [19:39] any difference in benchmarks? [19:41] not yet. This thing just has regression tests. [20:15] late night hacking I see [20:16] MasterDuke: do you have time for another stupid question wrt your gmp patch [20:16] sure [20:17] ok, this line in your diff: 329 + result = mpz_cmp_si(*b->u.bigint, 0) != 0; [20:17] shouldn't that be: 329 + result = mpz_cmp_si(*b->u.bigint, 0L) != 0; [20:18] dunno if it matters but in their demo examples they use 0L [20:23] i don't think it can make a difference for 0 [20:26] but i just changed them all and no difference [20:31] *** zakharyas left [20:34] *** Kaiepi left [21:08] *** sena_kun left [21:15] sigh, well it was worth a shot [21:26] hm. you don't even need the exponentiation. if you just use a bigint constant, e.g., 73786976294838206464, you get the same behavior [21:26] m: say +(42 xx 73786976294838206464) [21:26] rakudo-moar 85847d2f1: OUTPUT: «Cannot .elems a lazy list␤ in block at line 1␤␤» [21:27] i get `0` [21:41] ah ha! [21:43] in MVM_bigint_cmp [21:43] - return r; [21:44] + return r == 0 ? 0 : r < 0 ? -1 : 1; [21:45] rakudo tests pass...on to a spectest [21:47] MasterDuke++ [21:49] *** MasterDuke left [21:52] *** kawaii left [21:52] *** tbrowder left [21:54] *** chansen_ left [21:55] *** tbrowder joined [21:56] *** chansen_ joined [22:00] *** MasterDuke joined [22:03] mpz_cmp* is used in several places, perhaps more changes are necessary [22:07] *** kawaii joined [22:08] good catch, one other place did need a fix! [22:10] cool [22:10] unfortunately don't think it's going to correct any of the spectest fails [22:11] why is that? [22:12] most other uses of mpz_cmp_* were checking for equality, which did work the same as libtommath's [22:13] it's just greater/less than that was different [22:13] and the only use of one of those was in an unlikely branch of bigint_pow [22:15] so what kind of failures are you getting? [22:16] a couple are because gmp doesn't return an error code like libtommath does, it just aborts [22:16] m: say 42.expmod(-1,7) # gmp gives `Floating point exception (core dumped)` [22:16] rakudo-moar 85847d2f1: OUTPUT: «Error in mp_exptmod: Value out of range␤ in block at line 1␤␤» [22:17] m: say so (2⁴⁵⁵³⁵³⁵³⁴⁵³⁶⁴⁵³⁵³⁴⁵) # gmp gives gmp: overflow in mpz type Aborted (core dumped)` and i'm not sure why [22:17] rakudo-moar 85847d2f1: OUTPUT: «False␤» [22:18] m: say 2⁴⁵⁵³⁵³⁵³⁴⁵³⁶⁴⁵³⁵³⁴⁵ [22:18] rakudo-moar 85847d2f1: OUTPUT: «Numeric overflow␤ in block at line 1␤␤» [22:19] so we have to figure out to handle those kinds of cases [22:20] some are wrong values when right-shifting, which we had a lot of special handling for and i just got rid of, but maybe some of it needs to come back [22:20] and some are different num representations [22:21] m: say 2026887777243374/10**63 [22:21] rakudo-moar 85847d2f1: OUTPUT: «2.026887777243374e-48␤» [22:21] and gmp gives 2.0268877772433737e-48 [22:22] anyway, i'm off to bed. good progress today [22:23] sleep well [22:53] *** MasterDuke left