github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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?
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
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
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
MasterDuke k 20:30

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!