| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:16 SmokeMachine left 00:17 kawaii left, chansen_ left 00:18 SmokeMachine joined, chansen_ joined, kawaii joined 00:19 tbrowder left, tbrowder joined
nwc10 good *, #moarvm 07:17
nine Is it morning already? 07:20
nwc10 round here, it's never not morning 07:21
nine true, true 07:23
jnthn It's very morning... 07:56
nine jnthn: do you backlog the channel usually? 08:04
08:05 domidumont joined 08:08 MasterDuke joined
jnthn nine: Depends which, but this one I tend to, to at least pick off the easy questions I can answer quickly-ish :) 08:09
nine Ok, so no need to repeat the things I deep interesting for our architect in residence 08:10
jnthn I didn't yet get chance to read the article about GCC as JIT, to see which of the LLVM as JIT concerns it manages to avoid 08:13
08:51 bartolin left 08:52 bartolin joined, zakharyas joined 10:18 MasterDuke left 10:20 MasterDuke joined 10:39 lizmat_ joined 10:42 lizmat left 10:44 lizmat joined 10:48 lizmat_ left
MasterDuke nwc10: is relevant for our new hashes? 10:54
nwc10 good question. *Not* for the NQP-visible hashes, as they have randomisation 10:56
for the rest, not sure. And I *was* aware of that artikel, but had forgotten it
thanks for the reminder
somewhat busy with $stuff currently - hence why even the "good *" has been slacking at times 10:57
MasterDuke what do you mean "rest"? hashes used by moarvm internally? 10:59
nwc10 yes 11:02
MasterDuke ah. good that the nqp-visible ones definitely are safe 11:08
11:22 tobs left, tobs joined
nine Ah, take from the rich (element close to its natural bucket) and give to the poor (the one that's moving further and further away from its natural bucket) 11:23
That link contains an excellent explanation of what Robin Hood hashing is :)
nwc10: is the randomisation different per hash? 11:28
nwc10 yes 11:29
12:02 zakharyas left 12:18 harrow` left 12:19 harrow joined 12:44 Kaiepi left 13:14 zakharyas joined 14:49 lucasb joined 15:17 MasterDuke left 15:28 raku-bridge left, raku-bridge joined
jnthn Wow... 15:36
16:30 MasterDuke joined
nine On another look, the whole string situation in NativeCall is not that bad. Strings require a little extra handling but most of it is already there. After all strings were the only case even considered so far. 16:46
The CStruct's gc_cleanup function just has to take care of strings as well (it can leave non-inlined CStruct/CUnion/CArray members to their object's gc_cleanup). 16:47
One test case however is still an issue: sub take_and_free_struct_but_not_string(StructWithString $s is transferring-ownership(:except<$!s>)) is native($lib) { !!! }
If the struct is freed by the native function, we don't have a pointer to the encoded string anymore. The only place where that was stored is the CStruct and we must not access it anymore after transferring ownership as it may have been freed already (and is in my test ase) 16:49
MasterDuke is there a possible solution? 16:54
nine In theory CStruct's bind_attribute could create an object with CStr representation for bound strings and store that in the child_objs array instead of the original string. Those contain a pointer to the original MVM string and the encoded one and as mentioned yesterday it actually takes care of freeing the encoded string. 16:59
However it's not a perfect match as its MVMString *orig, not MVMObject *orig, i.e. it expects a VMString, not a HLL string object 17:00
But maybe I can make CStr a little more flexible 17:06
17:30 MasterDuke left 18:26 domidumont left
lizmat and another Rakudo Weekly News hits the Net: 18:38
18:41 japhb joined
cog_ lizmat++ 18:42
19:12 zakharyas left 20:30 brrt joined 20:46 zakharyas joined 21:37 SmokeMachine_ joined, SmokeMachine left, SmokeMachine_ is now known as SmokeMachine 21:49 zakharyas left 22:01 MasterDuke joined 22:02 Altai-man_ joined 22:04 sena_kun left 22:17 brrt left 23:43 MasterDuke left