github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:30
Geth MoarVM/2020.09: 1eb8851ea8 | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2020.09 release
 09:42
MoarVM/2020.09: 498de20f94 | Altai-man++ | VERSION
Bump VERSION for release
Geth MoarVM: Altai-man++ created pull request #1354:
2020.09 release		 09:43
MoarVM: 1eb8851ea8 | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2020.09 release
 09:54
MoarVM: 498de20f94 | Altai-man++ | VERSION
Bump VERSION for release
MoarVM: 346832e684 | Altai-man++ (committed using GitHub Web editor) | 2 files
Merge pull request #1354 from MoarVM/2020.09

2020.09 release
jnthn Altai-man++ # release 12:34
Altai-man Thanks to all the brave MoarVM hackers who made this release possible. \o/ 12:41
MasterDuke Altai-man++ 12:50
jnthn is timid enough to be mostly working in a branch :) 13:03
MasterDuke jnthn: now that there's been a release, any objection to merging github.com/MoarVM/MoarVM/pull/1352 ? 13:28
jnthn MasterDuke: None from me :) 13:29
I guess you'll take care of the NQP/Rakudo merges and bumps too? 13:30
MasterDuke cool, i'll do that and the accompanying nqp+rakudo ones in a bit
jnthn MasterDuke++ 13:31
I'll have to review the latest hash patch soon too; now we're post release, it'd be good to also get that in
MasterDuke hm. i'm doing all these gmp changes on a local checkout of tobs++'s branch. but i want to incorporate the changes from my simplification of isprime. guess i'll merge it, and then rebase tobs branch onto master. guess it should rebase cleanly 13:47
tobs MasterDuke: feel free. 13:52
I'm pretty slow on my branch because it turned out to take longer than that one evening last week. Today and tomorrow I'm mostly chained down by extra duties I thought were a good idea to take on a few months back... 13:55
If you want to work away on the GMP building because you have leftover weekend time, that's no problem for me. You can push my branch forward to create an entirely new one. 13:56
Otherwise I'll get back to it in due time.
MasterDuke tobs: i think it'll mean i can't push changes back to your branch. but that shouldn't really matter, cause most of my changes are actually using gmp. so you can edit your branch as you want and i'll just eventually extract these commits that implement gmp onto a new branch after yours is merge 13:57
*merged
Geth MoarVM: df77d3cf78 | (Daniel Green)++ | 8 files
Simplify and optimize isprime_I

Remove the `rounds` option. Rakudo only ever used a single (too large) value and the op does not appear to be used in the ecosystem. Instead, hardcode the value passed to the libtommath function to 40, chosen based on security.stackexchange.com/questio...raphic-saf Also, libtommath now returns false for 1, so remove that check in our ... (11 more lines)		 14:07
MoarVM: cd8e18280a | MasterDuke17++ (committed using GitHub Web editor) | 8 files
Merge pull request #1352 from MasterDuke17/simplify_and_optimize_isprime
timotimo i really wonder why gmp can be so much faster at that one simple thing; i wonder if it has some sort of optimization to get around storing data in a separate allocation or something? 14:13
MasterDuke which one simple thing? 14:16
timotimo oh, adding 1 to a big-ish number over and over 14:20
MasterDuke oh, right 14:21
86% of the way through bigintops.c... 14:24
timotimo i seem to remember, perhaps wrongly, that we couldn't use gmp because it does very strange things with error handling? 14:27
i wonde rwhat i'm confusing it with 14:29
MasterDuke well, i don't know what it does about errors. doesn't return an error value from every function like tommath does 14:30
timotimo "A limb means the part of a multi-precision number that fits in a single machine word. (We chose this word because a limb of the human body is analogous to a digit, only larger, and containing several digits.)" 14:33
"Since GMP types are implemented as one-element arrays, using a GMP variable as a parameter passes a pointer to the object. Hence the call-by-reference." - perhaps interesting or important detail 14:35
i can not find anything at all about error reporting in the gmp docs 14:43
MasterDuke guess you don't need to report them if you never make any 14:49
timotimo i guess there are just never any errors
yeah
MasterDuke arg! those relocation/-fPIC errors again. what did i do to fix it? 15:03
timotimo where do you get them? 15:11
i seem to recall it tells you what wasn't built with -fPIC?
MasterDuke it recommends building with -fPIC, but we already are 15:20
i fixed it, switched all references to the .so
and it built
time to ship it
oh hey, nqp built too 15:21
heh. does not pass tests. who's surprised? 15:22
not ok 64 - pow (int, positive) 15:23
# got: '5970554685064519004265641008828923248442340700473500698131071806779372733915289638628729'
# expected: '5970554685064519004265641008828923248442340700473500698131071806779372733915289638628729'
# got: '0' 15:24
# expected: '0'
timotimo equality checks dont work? 15:25
MasterDuke # got: '-1a' 15:26
# expected: '-1A'
doesn't look like there's a way to change that. might have to patch gmp 15:30
some are just a string comparison, i shouldn't have changed anything about that 15:32
hm. wonder if it's that gmp's function to get the size in a base might be off by +1? so when we alloc the string, it could be 1 too big? 15:38
could strlen the resulting string to get the exact size, but that seem wasteful 15:39
MasterDuke well, that works. will leave it for now, maybe will think of a better solution when firing on more cylinders 18:33
hm. i have it passing all nqp tests, except the ones that differ because of the case of hex numbers. i did have to change one test: from `nqp::iseq_n(nqp::div_In(box(1), $huge), 1e-300)` to `nqp::islt_n(nqp::div_In(box(1), $huge), 1e-300)` 18:57
and instead of using github.com/MoarVM/MoarVM/blob/mast....c#L31-L72 and this algorithm github.com/MoarVM/MoarVM/blob/mast...1166-L1185 i just converted to gmp floats and used their float division 19:01
ugh. i'm trying to patch gmp so our hex values match, and it looks like it should be a simple change, but i'm not picking it up in moarvm 19:26
MasterDuke huh. why can't i step into gmp functions in gdb? 20:04
jnthn Was the so build with debug symbols?
MasterDuke i think so
jnthn
.oO( this is so confusing... )
 20:05
MasterDuke '...with debug_info...'
jnthn Can you set a breakpoint in them?
MasterDuke i can make a change, rebuild, and the md5sum of the .so changes. but i don't see my changes reflected in what actually happens 20:06
hm. let me try
nope 20:07
i rebuilt with --optimize=0, same 20:11
well, the values are the same even if the case is different 20:12
i shall punt on this and look at the actual couple failing tests in rakudo's `make m-test`
brrt good * #moarvm 20:21
lizmat brrt o/ 20:46
brrt ohai lizmat 20:49
finally autumn right :-) 20:51
lizmat yeah... only cycled 35 km today... it was cold and windy and had to wear a coat for the first time in a looong time :-) 20:52
MasterDuke errors in 26 spectest files. i suspect a couple will be fixed if i fix what's wrong with m-test
jnthn o/ brrt 20:53
Was raining all day here. And cold enough that I wore a light jacket.
MasterDuke: You're already that far with the gmp branch? Wow :)
MasterDuke it was a lot of mechanical changes 20:54
but now we'll see if all the logic is the same. e.g., replaced tommath func x with gmp func y. theoretically they operate the same...
brrt \o jnthn 20:55
MasterDuke the problem right now i'm seeing is that the bigint here github.com/MoarVM/MoarVM/blob/mast...int.c#L113 is zero when it shouldn't be 21:05

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!