00:32 ZofBot joined 00:48 ggoebel joined 01:49 agentzh joined 02:48 ilbot3 joined 03:49 dalek joined, synopsebot6 joined 07:52 domidumont joined 07:55 Guest45611 joined 07:57 domidumont joined 10:53 domidumont joined
MasterDuke huh, you can't init an mp_int to a 64-bit value? 12:17
ah, mp_set_long_long 12:22
timotimo++ for pulling in a newer libtommath 12:23
12:41 agentzh joined
dogbert17 o/ 13:01
m: my @primes = grep { .is-prime }, 1 .. *; my @p = gather for 4000, 5, 100, 2000 -> $n { take start { @primes[$n] }; }; .say for await @p; # RT #127208
camelia Tried to get the result of a broken Promise
in block <unit> at <tmp> line 1

Original exception:
No such method 'is-prime' for invocant of type 'Mu'
in block at <tmp> line 1
in block at <tmp> line 1
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127208
dogbert17 what's wrong with this code? 13:02
sometimes it fails harder than above i.e. '*** Error in `/home/dogbert/.rakudobrew/moar-nom/install/bin/moar': realloc(): invalid next size: 0xb3e4e340 ***' 13:03
ok, so it has to do with thread not being entirely thread safe it seems. 13:06
grr, ok, so it has to do with *arrays* not being entirely thread safe ... 13:07
15:39 vendethiel joined
japhb dogbert17: I don't think you can assume any data structure that isn't *explicitly* thread-safe (like the concurrent queue that underlies a Channel) has any thread-safety guarantees. Too much performance penalty for that. 16:07
16:43 agentzh joined 16:59 agentzh joined
dogbert17 japhb, thx for the explanation. That means that there's no rakudo/MoarVM bug lurking here then 17:43
19:30 agentzh joined
MasterDuke dogbert17: well, it be nice if it failed more gracefully 19:40
19:43 agentzh joined 19:53 Ven joined, agentzh joined 20:26 agentzh joined
MasterDuke mp_get_long_long has this comment above its definition: /* get a platform dependent unsigned long long value */. on the platform we support, what are the possible sizes in bits an unsigned long long could be? 20:47
nm, google tells me long long is guaranteed to be at least 64-bit 20:54
dogbert17 MasterDuke, jnthn: this is what I've managed to find: gist.github.com/dogbert17/9b40d74d...c5167365ef 21:08
22:05 ggoebel joined
MasterDuke jnthn: any reason there's no assign_u NQP op? 22:31
m: my uint64 $a = 2**64-1; say $a 22:32
camelia -1
MasterDuke that ^^^ is being done via a decont_i -> MVM_6model_container_decont_i, instead of decont_u -> MVM_6model_container_decont_u 22:33
22:36 vendethiel joined 23:21 agentzh joined
MasterDuke i'm in a rabbit-hole. there are a whole lot of *_i functions, should there really be *_u versions of almost all? and should MVMHLLConfig add a bunch of uint_* stuff? 23:36