|
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
|
|||