github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:55
brrt good * 09:42
hope everyone is still healthy :-) 09:48
jnthn o/ brrt 09:51
Doing OK. You? :)
nwc10 \o 09:52
lizmat \o
brrt doing well as well 09:53
Geth MoarVM: 6baf0de4af | (Jonathan Worthington)++ | 3 files
Add a value_desc_cont container descriptor

This is a mild generalization of the Rakudo Scalar container descriptor that removes the reliance on precise P6opaque layout. It was planned to move this into MoarVM after the last round of Scalar refactors, however that was never actually done. Doing it now because it will make it much easier to use the offsets to have argument guards to decont/rw-check without having to do a function pointer call.		 16:21
Geth MoarVM: 1bd5f19e05 | (Jonathan Worthington)++ | src/6model/containers.c
Fix copy-pasta

Which breaks surprisingly little.		 16:30
travis-ci MoarVM build failed. Jonathan Worthington 'Add a value_desc_cont container descriptor 16:39
travis-ci.org/MoarVM/MoarVM/builds/669776383 github.com/MoarVM/MoarVM/compare/1...af0de4aff1
jnthn ah, just a race on NQP version 16:43
Geth MoarVM: 035eae1933 | (Stefan Seifert)++ | src/core/compunit.c
Fix interned callsites getting leaked when fixing up inlines

Interned callsites are no longer owned by the comp unit but by the instance. This means that we also do not free them when the comp unit gets garbage collected. It also means that it should be safe to reuse the existing pointer when adding an interned callsite to a comp unit (e.g. when inlining across comp unit boundaries).		 16:46
MoarVM: c7e75be60a | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/compunit.c
Merge pull request #1263 from niner/master

Fix interned callsites getting leaked when fixing up inlines
nine But it may be easier to fix now. Unless the fix is actually just freeing the old st->container_data (if there is one) in github.com/MoarVM/MoarVM/commit/6b...73e6ddR387 17:21
jnthn home time o/ 17:27
MasterDuke nine: adding `if (st->container_data) MVM_free(st->container_data);` gets `valgrind --leak-check=full raku --full-cleanup -e ''` to report `(definitely|indirectly|possibly) lost: 0 bytes in 0 blocks` 18:19
does say `still reachable: 1,677 bytes in 5 blocks` though
but those are all dlopen related 18:20
nine I know. I've been running with this patch for a week now 18:27
But I don't know if that's the right thing to do
MasterDuke PR and see if jnthn, timotimo, etc have any thoughts? 18:28
nine Yeah, that's the proper way to do this :) 18:29
nwc10 \o 18:55
[Coke] o/ 19:03
brrt \o 19:28

Powered by Cro and the Raku® Programming Language.

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

Thank you!