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