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.
timo m: my int $a = 5; sub do_it($x, $y is rw) { $a += $y }; say so do_it all(1, 2, 3, 4), $a; say $a 03:06
camelia True
80
timo m: my int $a = 5; sub do_it($x, $y is rw) { $y += 1 }; say so do_it all(1, 2, 3, 4), $a; say $a
camelia True
9
timo rw args with autothreaded subs is funky
MasterDuke timo: github.com/rakudo/rakudo/issues/17...-900393108 15:26
hm, just adding `uv_mutex_unlock(&body->head_lock); uv_mutex_unlock(&body->tail_lock);` before the destroys still gives the abort in the destroy 15:35
huh. we never unlock mutexes before destroying them 15:56
[Coke] during cleanup, do we want to unlock them? Would that potentially allow some other bit of code to continue when we were trying to shut down? 15:57
nine MasterDuke: no you can't just unlock those mutexes. You have to do it on the thread that locked them
There's just no way around proper thread cleanup. And that can only happen if those threads cooperate. 15:58
MasterDuke nine: have you looked at that issue? seems like there might be a problem with workers not getting cleaned up
nine MasterDuke: haven't looked at that specific issue, but I have working thread cleanup in github.com/MoarVM/MoarVM/commit/af...ec9e7516d0 and github.com/rakudo/rakudo/commit/8d...65155a13e0 16:04
MasterDuke cool, i'll see if those make a difference in this case 16:05
nine Those commits are on the moar_asan_fixes branches
MasterDuke prob won't be able to until later tonight 16:06
nine Good news: I have a fully working dispatcher based implementation of nqp::hllize and nqp::hllizefor! 19:38
Bad news is that we have a miscompilation on master that makes many tests fail with this new implementation :/
In foo(what => Int.^name) the call to the HOW method gets compiled into QAST::Op+{QAST::SpecialArg}(p6callmethodhow name :named<what>) <wanted> :before_promotion<?> :statement_id<2> name 19:40
See that :named<what>? That shouldn't be there and it confuses the lang-hllize dispatcher
nine Apparently caused by method arglist in Perl6::Actions: $_[2].named($name); 20:07
And I seem to have a fix :) 20:18
timo i wonder what other sitations this miscompile happens in? only with .^ i assume? 20:19
nine Well, it happens there because we re-use the existing QAST::Op carrying that named annotation. The fix accordingly is to create a new node and take only the stuff we need. 20:26
Could happen with other desugars as well
timo mhm 20:28
Geth MoarVM/new-disp: a9782fd5b0 | (Stefan Seifert)++ | 6 files
Add gettypehllrole op to facilitate writing hllization code in HLLs
 20:29
MoarVM/new-disp: 7897ff04e4 | (Stefan Seifert)++ | 7 files
Add lang-hllize dispatcher

This dispatcher checks if hllization is actually needed and if it is, delegates to a registered hllization dispatcher for the target language. This will replace the existing nqp::hllize and nqp::hllizefor ops.
MoarVM/new-disp: 4f04eef208 | (Stefan Seifert)++ | src/disp/boot.c
Give lang-hllize dispatcher an optional argument for language name

This makes lang-hllize suitable as a replacement for the nqp::hllizefor op.
timo i don't mean to offload "my" work onto you, but do you have an idea for the junction autothreading thing, nine? 20:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!