|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:16
vrurg_ joined
00:17
vrurg left
01:03
sena_kun joined
01:05
Altai-man_ left
03:02
Altai-man_ joined
03:05
sena_kun left
04:50
evalable6 left,
linkable6 left
04:51
evalable6 joined
04:53
linkable6 joined
05:03
sena_kun joined
05:05
Altai-man_ left
06:02
reportable6 left
06:05
reportable6 joined
07:03
ilogger2 joined
09:03
sena_kun joined
09:08
zakharyas joined
09:11
zakharyas left
09:17
zakharyas joined
|
|||
| MasterDuke | are new VMArrays created with any slots allocated? | 10:10 | |
|
10:11
squashable6 joined
|
|||
| MasterDuke | or is set_size_internal always called to allocate some slots? | 10:19 | |
| jnthn | Some things poke an already-allocated buffer directly in | 10:20 | |
| lizmat | maybe nqp::list(1,2,3) does ? | 10:44 | |
|
11:02
Altai-man_ joined
11:05
sena_kun left
|
|||
| jnthn | If it does presize, it goes via set_size_internal | 11:07 | |
| The only exceptions will be stuff like I/O where it gets, say, a buffer off the network and shoves it staright into the array body slot to avoid a copy. | |||
| MasterDuke | nqp::list(1,2,3) does set_size_internal | 11:34 | |
| and then npq::push's in a loop | |||
| is there any reason not to try and switch all VMArray use to FSA allocated storage? doing so would mean i could remove the if/else i currently have in set_size_internal and gc_free | 12:16 | ||
| jnthn | MasterDuke: Yeah but the case I mentioned above. | 12:18 | |
| MasterDuke | well yeah, have those spots allocate via the FSA also | 12:19 | |
| jnthn | MasterDuke: I think libuv probably can be made to do it though (alloc is a callback) | ||
| We don't want to copy; that's worse than the check. | |||
| MasterDuke | hm, didn't think about libuv. the other places should be pretty straightforward | 12:20 | |
| jnthn | Really it's a case of if the alloc callback is able to reach the thread context object | 12:21 | |
| MasterDuke | any reason github.com/MoarVM/MoarVM/blob/mast....c#L18-L23 can't take a tc? | 12:24 | |
| nine | MasterDuke: you'd have to get libuv to pass it to on_alloc | 12:25 | |
| MasterDuke | looks like i can get it from the handle github.com/MoarVM/MoarVM/blob/mast....c#L32-L33 | ||
| nine | yep, looks good | 12:26 | |
| MasterDuke | oh wait, that handle is a different type? | ||
| oh, it's a subclass, should be fine | 12:29 | ||
|
13:03
sena_kun joined
13:05
Altai-man_ left
|
|||
| [Coke] | Where in MoarVM is "decodeconf" op implemented? | 14:52 | |
| src/core/interp.c ? | 14:53 | ||
| MasterDuke | MVM_string_decode_from_buf_config | 14:57 | |
| src/strings/ops.c:1819 | |||
| [Coke] | ok, that's the function: where's the opcode that ties to it? | 14:58 | |
| src/jit/graph.c seems to have that mapping? | |||
| MasterDuke | src/core/interp.c:5408 | ||
| [Coke] | ah, so I was in the right spot, just didn't see the method call. Thanks. :) | 14:59 | |
| MasterDuke | np | ||
| [Coke] | s/method/ | ||
|
15:02
Altai-man_ joined
15:05
sena_kun left
15:10
MasterDuke joined
|
|||
| MasterDuke | first couple steps at getting all VMArrays to use FSA for storage and nqp builds and passes it's tests. rakudo builds, but core dumps during install. progress | 16:20 | |
| timotimo | nice | 16:25 | |
|
16:39
chansen_ left
16:41
chansen_ joined
16:42
tbrowder joined
16:43
MasterDuke left
17:03
sena_kun joined
17:05
Altai-man_ left
17:12
zakharyas left
19:02
Altai-man_ joined
19:05
sena_kun left
19:28
MasterDuke joined
20:46
MasterDuke left
21:03
sena_kun joined
21:05
Altai-man_ left
21:15
MasterDuke joined
23:02
Altai-man_ joined
23:05
sena_kun left
|
|||