github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 06:16
nwc10 and a slightly better morning now, as I have found the bug 08:03
things I did not know, that might be "obvious" to everyone else (or at least 3 of you) - if the value I'm trying to write out to a pointer happens to be 64 bit, it has to go in temporary register first, and no amount of casts or type thingies are going to save you (with a warning about what you did wrong) - it just gets truncated 08:04
and 08:05
does valgrind allocate heap memory with a totally different address layout to system malloc (ie top 32 bits of the pointer are zero ?)
because "my bug goes away completely when I run under valgrind" wasn't fun
sena_kun nwc10, a release blocker? 08:11
nwc10 no, private branch not even pushed anywhere
nine nwc10: what exactly are you working on? 08:32
nwc10 sp_add_I / sp_sub_I / sp_mul_I
MasterDuke interesting. think they can be made much faster? or is this a correctness fix? 08:44
nwc10 neither. but will push something soon. revisitng one of my stalled/misguided PR 08:45
I should go upstairs and see if the snow melted. I can only see sky from here, and plants in the rain shadow of the house 08:47
and blue sky, some clouds, and there is a shadow, implying ths strange bright thing is back
nine Geth AWOL again? 09:54
github.com/MoarVM/MoarVM/pull/1445 "Add a setup_notify handler and queue to nqp::signal" Setting up a signal handler happens on the IO eventloop thread. Thus when nqp::signal is done, one must not assume that the handler is already in place. Add setup_notify_queue and setup_notify_schedulee arguments, so we can notify the caller when the handler is setup to avoid race conditions. 09:55
sena_kun make: *** No rule to make target '3rdparty/cmp/cmp.h', needed by 'src/main.o'. Stop. 10:29
never mind 10:31
MasterDuke nine++ 10:54
lizmat nine: yeah, seems Geth is not PONGing to freenode's PINGs 12:16
and is therefor kicked off
sena_kun hm 12:31
Was anything changed in Rakudo related to kill.t?
I don't think it was, but rakudo does not pass the test reliably on 6.c-errata and 6.d-errata versions. 12:32
Master is fine with and without github.com/Raku/roast/commit/da922...f413b07d0f
The failed test is always "not ok 8 - did we get STDOUT" 12:33
Oh, no, it is TODOed. 12:34

Powered by Cro and the Raku® Programming Language.

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

Thank you!