Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:06 reportable6 left 00:07 reportable6 joined 01:43 linkable6 left, linkable6 joined 02:53 [Coke] left 02:55 [Coke] joined 04:25 evalable6 left, benchable6 left, committable6 left, reportable6 left, shareable6 left, bisectable6 left, quotable6 left, releasable6 left, statisfiable6 left, sourceable6 left, coverable6 left, tellable6 left, greppable6 left, bloatable6 left, linkable6 left, nativecallable6 left, unicodable6 left, notable6 left 04:26 releasable6 joined, greppable6 joined, quotable6 joined, coverable6 joined, tellable6 joined, sourceable6 joined 04:27 statisfiable6 joined, evalable6 joined, benchable6 joined, bloatable6 joined 04:28 shareable6 joined, linkable6 joined, nativecallable6 joined, bisectable6 joined 04:29 committable6 joined, notable6 joined, reportable6 joined, unicodable6 joined 06:07 reportable6 left 06:10 reportable6 joined 06:16 [Coke] left 06:24 [Coke] joined
Nicholas [* GOOD *] 06:39
nine *.map: *.GOOD 08:25
08:35 sena_kun left 08:36 sena_kun joined 08:39 frost joined
MasterDuke i don't remember if there were any comments on irc at the time, but any thoughts about github.com/MoarVM/MoarVM/pull/1470 ? 08:45
08:51 codesections left 08:52 codesections joined 11:23 evalable6 left 11:24 evalable6 joined 11:26 discord-raku-bot left, discord-raku-bot joined 11:27 Altai-man joined 11:29 Util left 11:30 Util joined, discord-raku-bot left 11:31 discord-raku-bot joined, sena_kun left 12:08 reportable6 left 12:10 reportable6 joined 12:29 frost left 12:58 [Coke] left 12:59 timo left 13:00 [Coke] joined 13:06 discord-raku-bot left 13:07 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:08 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:09 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:10 discord-raku-bot left, discord-raku-bot joined 13:11 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:12 discord-raku-bot joined, discord-raku-bot left, timo joined, discord-raku-bot joined 13:13 discord-raku-bot left, discord-raku-bot joined 13:14 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:15 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:16 discord-raku-bot left, discord-raku-bot joined 13:17 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:18 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:19 discord-raku-bot left, discord-raku-bot joined 13:20 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:21 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:22 discord-raku-bot left, discord-raku-bot joined 13:23 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:24 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:25 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:26 discord-raku-bot joined, discord-raku-bot left 13:27 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:28 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:29 discord-raku-bot joined, discord-raku-bot left 13:30 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:31 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:32 discord-raku-bot joined, discord-raku-bot left 13:33 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined 13:34 discord-raku-bot left, discord-raku-bot joined, discord-raku-bot left 13:35 discord-raku-bot joined 15:11 japhb left 15:17 japhb joined 18:07 reportable6 left 18:10 reportable6 joined 18:19 linkable6 left 18:22 linkable6 joined 18:28 Altai-man left 18:30 sena_kun joined
vrurg Are `nqp::uni*` thread-safe? 18:35
tellable6 2021-10-05T09:27:00Z #moarvm <jnthnwrthngtn> .tell vrurg It's about separate compilation; the compilation of a module should start with an empty GLOBAL and accumulate the things that are `use`d by it.
vrurg Wow, it was an old one... 18:36
japhb vrurg: Yeah, tellable6 is re-delivering messages it couldn't guarantee had been delivered properly before. 18:50
19:19 discord-raku-bot left, discord-raku-bot joined 20:14 sena_kun left 20:16 sena_kun joined
jnthnwrthngtn vrurg: They should be, but looks like something is wrong. Do you have a reproduction or can you get it to oops under rakudo-gdb-m and provide the stack trace? 20:42
The matter will probably give a big clue
vrurg jnthnwrthngtn: "They should be" is ok for now. I'm just trying to figure out the best fix for sub codename2proppref in unicodey.pm6. 20:43
Unfortunately, so far the best is to wrap the whole sub in a lock which is going to slow it down. :( 20:44
jnthnwrthngtn Ah, just saw the latest on the thread and it looks like there's actually some rakudo-level caching going on? 20:45
Yeah, that's that threadsafe at all
s:2nd/that/not 20:47
sourceable6 jnthnwrthngtn, No idea, boss. Can you give me a Code object? Output: 4===SORRY!4=== Error while compiling /tmp/HJi8w7z78Z␤Confused␤at /tmp/HJi8w7z78Z:1␤------> 328⏏4nd/that/not␤ expecting any of:␤ whitespace␤
jnthnwrthngtn hah 20:48
vrurg Phew, I was trying to figure out what you mean until the "not" was added. :)
jnthnwrthngtn I wonder if we could pre-calculate the hash at compile time
20:48 [Coke]_ joined
vrurg It mostly is. Caching is for what is overlooked, perhaps. 20:49
Or at least this is how I get it. I'm bad with unicode.
jnthnwrthngtn I suspect additions to this are rare, though, so an alternative is to never bind into the hash, but instead clone it, add the new key, and bind the copy in place of the old one (can't be `constant` then but, well, there's nothing constant about it anyway... 20:50
That's probably cheaper than the lock, anyway
20:50 [Coke] left
vrurg That's what I'm currently considering. 20:51
jnthnwrthngtn Although for a locking appraoch, note that unless $prop2pref also also written to, then it may be that only the nqp::ifnull(...) part needs wrapping in a `$lock.protect`
vrurg There might be extra misses on the same key, but I don't think it would be too costly to have it cached on a second pass.
jnthnwrthngtn Indeed
vrurg $prop2perf is a RO, but I don't like lock.protect as it may break inlinability. 20:52
So, atomic replace, after all. 20:53
Thanks!
BTW, I wonder how much would it cost to have a low-level lock-protected hash for cases like this? Locking at C-level shouldn't be that expensive. 20:56
jnthnwrthngtn Probably won't save that much, since nqp::lock/nqp::unlock are pretty direct mappings onto C stuff anyway 21:00
And especially if they're jitted the interpreter cost goes away
vrurg Low-level wouldn't require an object allocation though.
jnthnwrthngtn Which object?
vrurg nqp::lock needs a concrete with ReentrantMutex repr 21:01
Or whatever the repr is named.
jnthnwrthngtn Sure, but for cases like this it's long lived anyway, plus the allocation might not even be the dominant cost (dunno without profiling, but it's also calling the pthread mutex creation stuff either way) 21:02
vrurg Oh, and correct NQP/Raku level locking requires handling of exceptions which wouldn't be needed for C-level hash protection.
Yeah, I'm trying to multi-task and forgot that allocation "issue" I have excluded myself too. Only to get back to it again... :) 21:03
Bet the exception is a problem because, again, it's about phasers and inlineability. 21:04
s/Bet/But/ 21:10
22:04 sena_kun left 22:05 sena_kun joined