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:08 reportable6 left 00:09 reportable6 joined 01:04 frost joined
Nicholas good *, * 06:28
nine drakonis: it's still very much worth learning 06:36
drakonis certainly 06:38
nine Reading through the index I don't see anything that would be outdated by RakuAST. Maybe some details, but nothing major 06:41
06:59 Voldenet left 07:03 Voldenet joined 09:48 linkable6 left, evalable6 left 09:49 evalable6 joined 09:50 linkable6 joined 11:24 discord-raku-bot left, discord-raku-bot joined 11:49 Altai-man left 12:16 dogbert11 joined 12:17 dogbert17 left
jnthnwrthngtn RakuAST compilation still ultimately produces QAST, so even that part is still applicable :) 12:25
12:30 dogbert17 joined 12:32 dogbert11 left 12:44 sena_kun joined 12:58 dogbert17 left, dogbert11 joined 13:09 TempIRCLogger joined
MasterDuke ah right, kind of forgot about that. planned to stay that way indefinitely? 13:29
13:47 dogbert11 left, dogbert17 joined 14:18 dogbert17 left 14:21 dogbert17 joined 14:44 frost left 15:16 [Coke]_ joined 15:17 sena_kun left 15:18 [Coke] left, sena_kun joined 15:40 [Coke]_ is now known as [Coke]
jnthnwrthngtn MasterDuke: Well, certainly the distance from RakuAST to bytecode is fairly large. 16:22
And there's enough one would not want to have to do for every backend repeatedly 16:23
So something needs to go in that gap
lizmat Q: is an nqp::clone on an nqp::hash threadsafe ? 17:15
aka atomic?
18:43 rypervenche left 19:47 nebuchadnezzar left 19:48 nebuchadnezzar joined
jnthnwrthngtn lizmat: It'd need to iterate the source hash that it is copying (or at least work through its memory), and that's not atomic, so if something else writes the hash that is being cloned, it could be an issue. 19:51
It's no problem if other things are only reading the hash
So the typical pattern of "never mutate the hash, always clone it and mutate the clone and publish it" works
20:46 rypervenche joined
drakonis the move to rakuast would be able to allow the definition of both metaoperators and hyperoperators, yeah? 20:48
and is a recursive trait for subroutines a good idea? 20:55
specifically for stack optimizations related to that?
jnthnwrthngtn Syntax additions such as meta-operators will require slangs, which RakuAST is a prerequisite for, so it helps significantly in that direction, at least. 22:09
It'd be good to have some way to request a tailcall that either promises the current callframe will be re-used for the call or fails to compile if that for whatever reason can't be provided. 22:11
Not sure if a trait is really the right thing for that, more some special call form 22:14
It's less trivial than it looks, though, since if one looks at things like `sub foo($a) { with $a { foo(bar($a)) } }` the compilation of `with` implies a stack frame that binds the tested thing into `$_` at present, so "just replace the current frame" won't get you O(1) space. 22:16
And since there's currently no promise of tailcalls anywhere in the language, we freely produce closures for whatever block we might wish to in the compiler (of course, it's nice not to have the cost, so where possible they get optimized out). 22:17
So it's a question of how to provide a way to do this that isn't a stack growth foot gun. 22:19
22:31 linkable6 left, evalable6 left 22:32 linkable6 joined 22:33 evalable6 joined 23:33 evalable6 left, linkable6 left, evalable6 joined 23:35 linkable6 joined