01:47 ilbot3 joined 02:28 lizmat joined 04:01 lizmat joined 04:56 ggoebel joined 05:33 lizmat_ joined 06:25 domidumont joined 06:29 domidumont joined 07:04 lizmat joined 07:31 TheLemonMan joined 10:43 domidumont joined 11:00 synopsebot6 joined 12:31 domidumont joined 14:00 zakharyas joined 16:50 zakharyas joined 17:31 domidumont joined
timotimo nekovm.org/ - i wonder if this has anything interesting in it? 17:41
nekovm.org/doc/nxml - they have their own way of writing asts directly in their code, like our nqp::stmts and such nodes 17:47
their FAQ contrasts neko vs parrot 17:50
Neko is using the Boehm GC, which is a conservative multithreaded mark and sweep collector. However, since all calls to the GC are wrapped by the Neko API in vm/alloc.c, it might be possible to easily switch to another garbage collector in the future. 17:51
that's cute :P
18:33 zakharyas joined
jnthn I'd guess a bunch of options will run into needing write barriers. 18:35
"a single VM shouldn't be used to execute code on several threads at the same time."
Guess we won't be borrowing any neat threading ideas :) 18:36
19:00 vendethiel joined 19:49 brrt joined
brrt interesting thing 19:59
20:30 ggoebel joined 20:31 lizmat joined 20:32 leego joined 20:41 lizmat joined 21:13 lizmat joined 21:28 synopsebot6 joined
japhb What's the MoarVM idiom for writing out debugging info, akin to fprintf(stderr, ...) but safe WRT threads, GC, libuv, etc.? 23:22
I'm trying to figure out the problem with getting Malformed UTF-8 on binary stdout from an async proc, and I can't see where the binaryness is getting lost, so now I'm going to try debug output ... 23:25
geekosaur had been wondering... was it stdout, or stderr? 23:35
japhb stdout
Thankfully, all the IO happens on a single thread, so I won't get a complete mess in the debug output, but it is callback-and-bespoke-structure hell because libuv, so it will be "interesting" to figure out. 23:37