|
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
|
|||