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.
00:04 linkable6 left, evalable6 left 00:05 linkable6 joined 00:07 reportable6 left 01:05 evalable6 joined 01:51 kjp left 01:54 kjp joined 02:51 frost joined 03:10 reportable6 joined 03:24 Kaiepi left 03:25 Kaiepi joined 04:34 kjp left 04:36 kjp joined 04:43 frost left 05:04 frost joined 05:41 frost left 06:04 frost joined 06:08 reportable6 left 06:10 reportable6 joined 07:10 frost left 07:34 japhb left 07:36 japhb joined
Nicholas good *, * 07:49
08:23 frost joined 08:58 squashable6 left 09:11 frost left
MasterDuke huh. github.com/MoarVM/MoarVM/pull/1650 just passed a spectest locally, but it's throwing a fit in CI 09:27
nine MasterDuke: the free() call in CStruct's, CPPStruct's and CUnion's gc_cleanup was commented but is no longer in your PR 09:30
MasterDuke oh, right. thought i'd see if it was ok now. seemed to be locally, but i guess not 09:31
nine I wonder, if that's the remaining source of memory leaks in our Cro applications. After all Cro uses OpenSSL via NativeCall for TLS
Nicholas I can't replicate the CI failures locally. Which is frustrating 09:33
nine Feels like it's always like that :/ 09:34
MasterDuke nine: have you run your app under heaptrack? 09:41
nine AFAIR yes 09:42
10:00 squashable6 joined 10:48 [Coke] left 10:54 frost joined
Nicholas Oh my. I think that MVM_string_utf8_encode_substr effectively ignores the `start` and `length` parameters. 11:06
ie it never actually does substrings
nine wat?
Nicholas yes. but nothing ever uses it for substrings
MasterDuke check some of the commentary here github.com/MoarVM/MoarVM/pull/1600 11:08
oh, there aren't actually a whole lot of comments. i think there was some chat here about this around then 11:09
this github.com/MoarVM/MoarVM/blob/mast....dasc#L445 seems odd 11:11
11:12 Geth left
Nicholas MasterDuke: I don't know enough about x86_64 assembly or x86_64 addressing modes to answer. But I can ask "why do you think it looks odd?" because I have some guesses 11:13
MasterDuke because we're assigning to .n64, but then moving .i64. it seems to work ok (running nqp::nan in a loop and printing at the end give NaN), but it looks off 11:15
nine MVMRegister is a union 11:16
.i64 and .n64 point at the same memory location and have the same size. Those parameters are the only thing the CPU cares about. 11:17
Nicholas aha, that wasn't the thing I was thinking. I already knew that it was a union.
I was assuming that the mov64 then the mov are needed because of addressing mode limitations
nine And that's correct as well 11:18
11:19 frost left
MasterDuke any reason not to use .n64? 11:21
nine Could be that the compiler or dynasm would complain about the type mismatch. And why fix what isn't broken? 11:32
lizmat because then we wouldn't have this discussion again in the future? 11:36
MasterDuke type mismatch? i did actually just see a compiler that complained that tmp.i64 was being used uninitialized. arguably it should know it is initialized... 11:37
nine Compilers are just the worst :D 11:38
MasterDuke looks like Geth is down 11:57
lizmat yes, it is, but it seems to be unable to connect to libera 12:02
kicking it now
12:02 Geth joined
lizmat MasterDuke: where did you do a commit? 12:03
MasterDuke github.com/MoarVM/MoarVM/pull/1651
lizmat ok, I don't have the rights to re-send it :-( 12:04
MasterDuke well, i did just mention it, so not that pressing for Geth to repeat
12:05 [Coke] joined 12:06 Geth left, Geth joined 12:07 reportable6 left 12:12 kjp left 12:14 kjp joined 12:41 mst joined
Nicholas MasterDuke: I think we should go a bit further, and do something like github.com/nwc10/MoarVM/tree/direc...nativecall 12:41
my choice of function names isn't very good 12:42
also, I think we should keep "wrapper" functions for (libc) malloc, free, realloc, calloc that call `panic` on failure
(which need a name...)
AFK& # lunch
12:45 mst left
MasterDuke nice. but why not a MVM_string_utf16_encode_malloc? 12:45
12:47 mst joined
Nicholas I'm not even sure if we "need" the ascii version. I was assuming that the need for UTF16 was pretty rare 13:04
this is a guess. I didn't do any research
lizmat isn't UTF16 native to WIndows ? 13:05
13:09 reportable6 joined
Nicholas true. 13:09
I don't know what's worth doing.
but I think basically MVM_string_utf16_encode_substr_main is a bit more complex than the equivalents in ascii.c and in utf8.c 13:10
so I didn't really feel like copy-paste-edit crimes there too
MasterDuke couldn't github.com/nwc10/MoarVM/commit/4cb...e4e3144009 still be wrapped in an `#ifdef MVM_USE_MIMALLOC`? 13:14
Nicholas yes. Oops. I was in a hurry with that commit 13:27
14:12 squashable6 left 14:54 discord-raku-bot left, discord-raku-bot joined 15:04 frost joined 15:05 discord-raku-bot left 15:08 discord-raku-bot joined 15:12 discord-raku-bot left 15:13 discord-raku-bot joined 15:35 frost left 15:58 MasterDuke left 16:14 MasterDuke joined, squashable6 joined 18:06 reportable6 left 19:07 reportable6 joined 20:16 Kaiepi left 20:17 Kaiepi joined, Kaiepi left 20:18 Kaiepi joined 21:04 MasterDuke left 21:21 MasterDuke joined