|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:26
Altai-man_ joined
00:29
sena_kun left
01:53
Kaiepi left
01:59
Kaiepi joined
02:27
sena_kun joined
02:29
Altai-man_ left
04:26
Altai-man_ joined
04:29
sena_kun left
06:27
sena_kun joined
06:29
Altai-man_ left
08:26
Altai-man_ joined
08:29
sena_kun left
09:02
Kaiepi left
09:04
Kaiepi joined
|
|||
| MasterDuke | if anybody is interested, i've a couple open questions from yesterday. i got timotimo to nibble on some, but he escaped the hook | 09:47 | |
| why is github.com/MoarVM/MoarVM/blob/mast...1116-L1117 here? couldn't it be moved much earlier to not do all that extra work? | 09:48 | ||
| github.com/MoarVM/MoarVM/blob/mast...ons.c#L448 is the only call that doesn't explicitly pass NULL for the return_address parameter | |||
| any reason not to bail out immediately? do we still have to go through the body of the loop if it's not NULL? | |||
| also | 09:49 | ||
| MVM_HASH_(GET|BIND) and maybe some of the other hash-related macros can throw, but they only take one element of a malloced array as an argument | |||
| any reason not to change them to (also?) take the base array so it can be freed before the throw? i haven't checked all the calls to them yet, maybe it needs a flag to decide whether or not it's safe to free what's passed? | 09:50 | ||
| also | |||
| not sure about`repr_data` (and similar things) in a bunch of cases (e.g., github.com/MoarVM/MoarVM/blob/mast...#L25-L37). should the alloced stuff be freed before the throw? | 09:52 | ||
| nine | MasterDuke: yes, the return_value check could be done earlier. But if that exception gets throws something is seriously wrong anyway and efficiency is the least of our worries. AFAICT this could only happen if there's a bug in the compiler or VM | 10:00 | |
| No reason not to extend MVM_HASH_(GET|BIND) AFAICS | 10:04 | ||
| In the case of CArray's repr_data, yes I think it should be freed and even more importantly st->REPR_data set back to NULL because that's what we test when checking if a type is composed. | 10:07 | ||
| Amending my answer to MVM_HASH_(GET|BIND), I think we'd need 2 versions of those macros. The current one and one that free()s some data. Or even takes a cleanup block and simply runs that. | 10:08 | ||
|
10:28
sena_kun joined
10:29
Altai-man_ left
11:17
MasterDuke left
11:53
konvertex joined
12:22
MasterDuke joined
12:26
Altai-man_ joined
12:29
sena_kun left
12:56
patrickb joined
13:02
Voldenet left
13:08
Voldenet joined,
Voldenet left,
Voldenet joined
14:23
rypervenche left,
patrickb left
14:25
konvertex left
14:27
sena_kun joined
14:29
Altai-man_ left
14:38
rypervenche joined
|
|||
| MasterDuke | in github.com/MoarVM/MoarVM/blob/mast...#L749-L758 could the HASH_BIND occur right after the malloc (so i could pass entry as the newly created to-be-freed argument)? | 15:23 | |
|
15:27
zakharyas joined
15:30
gugod left
|
|||
| MasterDuke | hm. everything builds ok if i do so. nqp passes it's tests. rakudo passes a spectest, but there's a consistent fail in t/02-rakudo/repl.t | 15:35 | |
|
15:52
Kaiepi left
15:53
Kaiepi joined
15:56
Kaiepi left,
Kaiepi joined
15:57
domidumont joined
16:02
Kaiepi left
16:05
Kaiepi joined
16:19
zakharyas left
16:26
Altai-man_ joined
16:29
sena_kun left
|
|||
| timotimo | have you run it without prove to see what the failure looks like exactly? | 16:59 | |
| the repl test checks stdout and stderr i think? | |||
|
17:18
konvertex joined
17:41
domidumont left
|
|||
| MasterDuke | The spawned command '/home/dan/Source/perl6/rakudo/rakudo-m' exited unsuccessfully (exit code: 0, signal: 6) in sub is-run-repl at /home/dan/Source/perl6/rakudo/t/packages/Test/Helpers.pm6 (Test::Helpers) line 61 in block <unit> at t/02-rakudo/repl.t line 223# You planned 45 tests, but ran 33 | 18:12 | |
| ugh. also i thought i could just add one parameter to MVM_HASH_(BIND|GET) and free if there's an exception, but sometimes the thing that would need to be freed is FSA allocated | 18:18 | ||
| i could add another size parameter and if it's not NULL use fixed_size_free. or maybe it is better to pass a cleanup block like nine suggested | 18:19 | ||
|
18:27
sena_kun joined
18:29
Altai-man_ left
19:20
lucasb joined
20:12
zakharyas joined
|
|||
| MasterDuke | nine: how were you thinking of passing a cleanup block? make it a variadic macro? | 20:15 | |
| nine | MasterDuke: like MVMROOT | 20:18 | |
| MasterDuke | k | 20:19 | |
|
20:27
Altai-man_ joined
|
|||
| MasterDuke | think i should do the same for MVM_ASSIGN_REF? it MVM_panic()s instead of MVM_exception_throw_adhoc | 20:27 | |
| jnthn | I'd think anything that goes wrong in MVM_ASSIGN_REF is going to be pretty fatal | 20:28 | |
|
20:29
sena_kun left
|
|||
| MasterDuke | k | 20:30 | |
|
20:47
rypervenche left
21:19
rypervenche joined
21:42
zakharyas left
22:27
sena_kun joined
22:29
Altai-man_ left
23:34
Kaiepi left
23:35
Kaiepi joined
|
|||