timotimo i think the problem was that there used to be a folder where we had the 3rdparty code directly in the moar repository and i decided we should have it as a submodule instead 00:05
but gits all over the country exclaimed "cannot unlink 3rdparty/foobar because it's not empty!"
jnthn ah, that sounds like exactly the situation samcv's PR creates too? 00:06
So yeah, maybe we do want my "different directory name" workaround
timotimo i believe it happens mostly because .o files and such will be left over in there ... but isn't libatomic_ops only header files? maybe it can work out after all 00:07
jnthn Hmm...think its configure process must create some artefacts though? 00:10
timotimo quite possibly 00:11
maybe we want to make extra sure this time
timotimo jnthn: when you wrote about the LeakTracer you used for the Promise.in leak, you said "Also, darn, the binary format loads faster at least, when it works :P"; I'm not sure if I interpreted that correctly; is something wrong with the binary format? other than perhaps if you uncleanly exit it won't load just yet ... 01:14
brrt good * 07:21
jnthn timotimo: It may have been version skew in moar-ha or some similar issue 09:55
pmurias a MoarVM segfault is always a bug? 10:10
nqp::bindpos_i on a type object segfaults
jnthn Yes, that's worth reporting (it'll just be a missing IS_CONCRETE check) 10:15

Powered by Cro and the Raku® Programming Language.

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

Thank you!