Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-12

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:32 ZofBot joined #moarvm
00:48 ggoebel joined #moarvm
01:49 agentzh joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:49 dalek joined #moarvm
03:49 synopsebot6 joined #moarvm
07:52 domidumont joined #moarvm
07:55 Guest45611 joined #moarvm
07:57 domidumont joined #moarvm
10:53 domidumont joined #moarvm
12:17 MasterDuke huh, you can't init an mp_int to a 64-bit value?
12:22 MasterDuke ah, mp_set_long_long
12:23 MasterDuke timotimo++ for pulling in a newer libtommath
12:41 agentzh joined #moarvm
13:01 dogbert17 o/
13:01 dogbert17 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
13:01 camelia rakudo-moar 0f289a: OUTPUT: «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␤␤»
13:01 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127208
13:02 dogbert17 what's wrong with this code?
13:03 dogbert17 sometimes it fails harder than above i.e. '*** Error in `/home/dogbert/.rakudobrew/moar-nom/install/bin/moar': realloc(): invalid next size: 0xb3e4e340 ***'
13:06 dogbert17 ok, so it has to do with thread not being entirely thread safe it seems.
13:07 dogbert17 grr, ok, so it has to do with *arrays* not being entirely thread safe ...
15:39 vendethiel joined #moarvm
16:07 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:43 agentzh joined #moarvm
16:59 agentzh joined #moarvm
17:43 dogbert17 japhb, thx for the explanation. That means that there's no rakudo/MoarVM bug lurking here then
19:30 agentzh joined #moarvm
19:40 MasterDuke dogbert17: well, it be nice if it failed more gracefully
19:43 agentzh joined #moarvm
19:53 Ven joined #moarvm
19:53 agentzh joined #moarvm
20:26 agentzh joined #moarvm
20:47 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:54 MasterDuke nm, google tells me long long is guaranteed to be at least 64-bit
21:08 dogbert17 MasterDuke, jnthn: this is what I've managed to find: https://gist.github.com/dogbert17/9b40d74dd32a526ca12184c5167365ef
22:05 ggoebel joined #moarvm
22:31 MasterDuke jnthn: any reason there's no assign_u NQP op?
22:32 MasterDuke m: my uint64 $a = 2**64-1; say $a
22:32 camelia rakudo-moar 212cc8: OUTPUT: «-1␤»
22:33 MasterDuke that ^^^ is being done via a decont_i -> MVM_6model_container_decont_i, instead of decont_u -> MVM_6model_container_decont_u
22:36 vendethiel joined #moarvm
23:21 agentzh joined #moarvm
23:36 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?

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary