github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:07 Kaiepi left 01:44 ZzZombo left 02:29 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 05:20 robertle left 05:21 brrt joined 05:22 p6bannerbot sets mode: +v brrt
brrt \o 05:26
samcv \o 05:27
nwc10 o/ 05:30
brrt ohai 05:32
my fork-safety thread crashes because i'm shutting down the io loop too late, it seems :-( 05:46
samcv brrt: so i've been busy for the last bit with my job search, whati's this fork safety thing about? 05:48
fixing a crash?
brrt no 05:53
it's about allowing fork() in MoarVM
samcv oh nice :)
brrt++
brrt in POSIX fork() will copy memory but not threads
since we have a bunch of background threads, that might mean that the child inherits memory that cannot be cleaned up 05:54
including locks that may be held, etc
solving that in the general case of having user threads, is very difficult 05:55
samcv by doesn't copy threads, do you mean subthreads? or what
brrt the child process only ends up with one thread, which is the one that derrives from the fork()-ing threads
MoarVM will have at least a spesh thread, maybe an IO thread, maybe a debugserver thread 05:56
and potentially many user thredas
*threads
samcv so you're saying those threads need to be forked too? or something
since it's not a single process?
or am i totally misunderstanding things
brrt That's almost correct 05:57
you can't make fork() create new threads on the child process
so what you have to do, to ensure that the child process doesn't get stuck with memory it cannot use, is to stop the threads in the parent process, fork then start them again (in the parent, and maybe in the child process) 05:58
samcv ah ok i understand it now 05:59
brrt but we couldn't stop either the IO loop thread, or the spesh thread, so far, so I had to add that first 06:00
so I think i know what's going on now 06:22
06:23 robertle joined 06:24 p6bannerbot sets mode: +v robertle 06:29 domidumont joined 06:30 p6bannerbot sets mode: +v domidumont
brrt hmm, shutting down the uv loop causes a deadlock now 06:33
well, that's progress at least :-)
06:34 patrickb joined, p6bannerbot sets mode: +v patrickb
Geth MoarVM/fork-safety: 0a6fdaec28 | (Bart Wiegmans)++ | src/io/eventloop.c
[IO] Redundant MVM_gc_mark_thread_blocked causes a panic

Maybe panicking is an overreaction, but the mark_thread_block was redundant, as MVM_thread_join would call it again.		 06:38
07:01 brrt left 07:36 lizmat joined, p6bannerbot sets mode: +v lizmat 08:15 zakharyas joined, p6bannerbot sets mode: +v zakharyas 09:01 patrickb left 09:47 patrickb joined, p6bannerbot sets mode: +v patrickb 10:04 ZzZombo left 10:12 domidumont left 10:38 brrt joined 10:39 p6bannerbot sets mode: +v brrt
brrt hmm, i need to figure out how to stop the io event loop 10:44
11:01 robertle left 11:04 zakharyas left 11:05 zakharyas joined 11:06 p6bannerbot sets mode: +v zakharyas 11:11 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 11:22 lizmat left 11:23 lizmat joined 11:24 p6bannerbot sets mode: +v lizmat
brrt our windows support is not getting better it seems.... 11:28
t/hll/06-sprintf.t breaks
11:39 zakharyas left 12:15 Kaiepi joined 12:16 p6bannerbot sets mode: +v Kaiepi
brrt how even *is* a MoarVM opcode exposed to NQP? 12:30
and more importantly, why doesn't it just work
timotimo they are registered in QASTOperationsMAST 12:31
brrt hmmm
so I need to modify nqp source to register a new op 12:32
and... that doesn't happen automatically based on the MAST/Nodes.nqp or MAST/Ops.nqp 12:34
thank you timotimo++, now I understand a lot more 12:37
13:00 zakharyas joined 13:01 p6bannerbot sets mode: +v zakharyas
Geth MoarVM/master: 6 commits pushed by (Paweł Murias)++, (Bart Wiegmans)++ 13:02
13:03 domidumont joined, p6bannerbot sets mode: +v domidumont 13:05 zakharyas left, zakharyas joined 13:06 p6bannerbot sets mode: +v zakharyas 13:14 domidumont left
brrt .tell pmurias I merged your PR 13:22
yoleaux brrt: I'll pass your message to pmurias.
13:23 robertle joined 13:24 p6bannerbot sets mode: +v robertle
brrt I think the MVMROOT there isn't necessary because we already assigned the object to the register... 13:29
oh, hang on, the 'result' variable may be overriden
timotimo there's some extra stuff in the operations like "this argument shall have a decont generated automatically" 13:41
13:41 brrt left 13:54 brrt joined 13:55 p6bannerbot sets mode: +v brrt 14:04 zakharyas left, zakharyas joined 14:05 p6bannerbot sets mode: +v zakharyas
Geth MoarVM: 3abd2888bc | (Bart Wiegmans)++ | 4 files
[decodelocaltime] Throw error on failure

localtime_r and localtime_s can both fail, and we should throw an error if so, otherwise how is the user to know?		 14:17
14:38 avar left, avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 14:39 p6bannerbot sets mode: +v avar 15:03 zakharyas left 15:09 lizmat left 15:15 zakharyas joined, p6bannerbot sets mode: +v zakharyas 15:21 robertle left 15:46 patrickb left
timotimo hm, wanted to combine usage of debugserver with gdb and seemingly didn't do it right 16:01
brrt what's going wrong 16:03
timotimo i did something and the debug client got stuck :)
let me try it again and see if i can't figure it out 16:07
16:13 brrt left
timotimo hum. 16:15
16:16 ggoebel_ left
timotimo well, i can just look closely at the code and fix it that way i'm sure 16:16
m) it was a mistake in the C code, not the nqp code 16:20
16:31 ggoebel_ joined 16:32 p6bannerbot sets mode: +v ggoebel_ 16:45 domidumont joined 16:46 p6bannerbot sets mode: +v domidumont 16:47 robertle joined 16:48 p6bannerbot sets mode: +v robertle
timotimo i'd love the rakudo compilation to speed up some more :D 16:49
17:07 robertle left, robertle joined 17:08 p6bannerbot sets mode: +v robertle 17:57 zakharyas left 18:00 lizmat joined 18:01 p6bannerbot sets mode: +v lizmat 18:04 brrt joined 18:05 p6bannerbot sets mode: +v brrt
brrt timotimo: wouldn't we all 18:10
timotimo INSERT INTO types VALUES ('54','NQPArrayIter',json_object('typename', 'NQPArrayIter','type', null,'managed_size', 64),json_object()); 18:19
INSERT INTO types VALUES ('102','BOOTStrArray',json_object('typename', 'BOOTStrArray','type', null,'managed_size', 56,'has_unmanaged_data', 1),json_object());
looks good, doesn't it? 18:20
now there can be any kind of data in there! 18:23
brrt hmm, pretty nice 18:30
what's the backend database?
Geth MoarVM/profiler-extra-type-info: 4 commits pushed by (Timo Paulssen)++ 18:35
timotimo the backend database is sqlite3
oh, cute! github gives you an url where you can create a PR when you've "git push"ed a new branch 18:36
tadzik oh :) I thought only gitlab did that
18:50 Kaiepi left
Geth MoarVM/master: 6 commits pushed by (Timo Paulssen)++ 18:51
brrt I think I figured out how to stop the libuv loop at a distance 18:53
timotimo is it spooky?
brrt not very 18:57
but i'm not 100% sure it will work correctly if we're actually connected to a socket or something
timotimo kicking the debugserver client off is a valid thing to do. not polite, but acceptable 18:59
maybe we should send an event for that case asking to reconnect, and suspend all threads after coming back from the fork on this side of it
also, the debugserver may want to expose controls for what the forked whild does, i.e. should it continue running a debugserver, but on a different port?
brrt hmmm 19:01
it's a good question
but, it is also something that doesn't quite work under gdb
so the state of the art is not really all that exciting 19:02
19:02 domidumont left
timotimo so wouldn't it be cool if we did it better ;) 19:02
brrt :-) 19:14
19:34 zakharyas joined, p6bannerbot sets mode: +v zakharyas 19:50 brrt left 20:03 Kaiepi joined 20:04 p6bannerbot sets mode: +v Kaiepi 20:41 zakharyas left 20:50 Kaypie joined 20:51 p6bannerbot sets mode: +v Kaypie 22:12 Kaypie left
timotimo INSERT INTO types VALUES ('395','Rakudo::Iterator::Mappy-keys',json_object('typename', 'Rakudo::Iterator::Mappy-keys','type', null,'scdesc', 'gen/moar/CORE.setting','repr', 'P6opaque','managed_size', 48),json_object()); 22:21
^- i can now tell objects that are rakudo and nqp builtins apart from objects that aren't (except if they were compiled with the exact same path as the CORE.setting or similar files) 22:22
so if it's a class from the core setting, i can link it to the docs immediately!
23:13 Voldenet left 23:15 Voldenet joined, Voldenet left, Voldenet joined, p6bannerbot sets mode: +v Voldenet 23:16 p6bannerbot sets mode: +v Voldenet 23:24 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke

Powered by Cro and the Raku® Programming Language.

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

Thank you!