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.
MasterDuke brrt++ 01:35
lizmat sometimes I wonder if it would make sense to have a type of strand that would consist of elements with a join character 12:30
Masterduke: or do we have something like that already?
tellable6 lizmat, I'll pass your message to MasterDuke
MasterDuke . 19:16
tellable6 2023-06-11T12:30:45Z #moarvm <lizmat> Masterduke: or do we have something like that already?
MasterDuke we have a bunch of heuristics in MVM_string_join about whether to create a new string of strands or a new flat string 19:20
but we don't have a different string/strand type that's multiple elements and a single separator (unless there are just two parts to join of course) 19:23
completely random question. some of our ops have concreteness checks in interp.c, some have them in the implementing function, and some have them duplicated. is any one of those universally better than the others? 19:38
istr that putting them in the implementing function was a bit redundant when the op got jitted, since the jit would do it also 19:39
if that's correct, then moving them out of the implementing function and into interp.c would make sense. but i'm not at all confident about that actually being the case, and even if it is, how to know if/when that's true 19:40
nine That's definitely true. Even better is that with syscalls the dispatcher and spesh can remove redundant checks as well 20:23
jnthn What nine++ said, the right direction is most ops moving towards being syscalls 22:33
Since those have a very generalized framework for eliminating the repr/type checks 22:34
MasterDuke hm. any suggestion as to which should be converted first? 22:41
jnthn Anything I/O related fits 23:14

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!