jnthn timotimo: In 7d31a884f80 in the gc_free function of compunit when it evacuates string data into separate buffers, should it not clear the foreign_memory flag? 12:24
jnthn fears this causes a memory leak :(
timotimo oh! 12:42
jnthn valgrind evidence is suggestive that it does
Confirmation soon
But a leak in gc_free proportional to how many EVALs I do is suggestive 12:43
Just seeing if they disappear with a revert of the two
Yes, indeed. Those leaks go with the revert.
I'll revert them for the release
timotimo really does sound like the clearing of the flag ought to happen
OK
jnthn Because I'm not comfortable we can test the fix well enough
But I'm fine with them being unreverted post-releaes and the fix put in
Just like to keep the risk down on releases :) 12:44
timotimo yes, indeed 12:44
dalek arVM: 47629f3 | jnthn++ | src/6model/reprs/MVMCompUnit.c:
Revert "prevent access to un-deserialized strings in gc_free"

This reverts commit 530f3cfdf57bacd953dff9a0c9706e4034a4da6d.
12:45
arVM: b8f7229 | jnthn++ | src/ (4 files):
Revert "share some string's memory with compunit memory"

This reverts commit 7d31a884f80ab3586df916d421995780f4da69c1. It causes a memory leak by not clearing the foriegn_memory flag. This is likely an easy fix, but we can't test it enough ahead of the release. Thus, reverting this for the release. 0ef9963 | jnthn++ | docs/ChangeLog: ChangeLog for 2016.12.
timotimo foriegn, eh? :)
jnthn Bah, these foriegners who cant English :P
Feel free to glance the changelog for gammaros 12:47
dalek arVM: 28ccad7 | jnthn++ | VERSION:
Bump VERSION.
timotimo oh
can do
the only thing i see is that there's three entries that end in a . 12:50
jnthn d'oh
timotimo other than that it looks good
dalek arVM: 0595ff8 | jnthn++ | docs/ChangeLog:
Be consistent; timotimo++.
jnthn OK, just doing an NQP/Rakudo build on this release version to be sure all is well enough 12:51
timotimo good blogpost, too :) 12:56
jnthn The module behind it was a bit tricky in places :) 12:58
timotimo i can imagine 13:00
getting something priority-queue-like in place
does it time code running on the threads to see if they run past another activation? 13:01
jnthn No 13:03
It tries to make sure that all the consequences of a particular event in virtual time have chance to contribute anything new to schedule 13:04
timotimo right, that's what i imagine a priority queue to be used for
jnthn Yeah, that may be a smarter data structure than I what I got :)
timotimo can be refactored later :) 13:06
jnthn It's the biggest MoarVM relesae yet! www.moarvm.org/releases/ 13:07
(3.3MB!)
timotimo must be new unicode additions 13:08
jnthn Release tagged 13:10
Lunch now; will take care of website update afterwards
timotimo \o/
dalek href="https://moarvm.org:">moarvm.org: c102480 | jnthn++ | / (2 files):
Update site for 2016.12 release.
14:06
jnthn There we go :) 14:07
dogbert17 o/ 15:24
does this snippet look suspicious in any way? 'for ^1 { IO::Socket::INET.new( :port($_), :host("127.0.0.1") ); CATCH {next}; say $_~" is open" }' 15:25
moritz yes 15:31
dogbert17 why
moritz I believe you can't open port 0
or does that have some sort of special semantics? 15:32
dogbert17 fair enough :-) I stole it from a MoarVM bug report, the loop went from 0..4000 in that example
moritz also, if you don't handle the exception in CATCH, it's rethrown
you need CATCH { default { next } } 15:33
dogbert17 ok, I'll try that
if I valgrind this snippet, old version or moritz corrected version I get an: 15:35
==9818== Invalid read of size 4
==9818== at 0x41AA07F: uv__platform_invalidate_fd (in /home/dogbert/repos/rakudo/install/lib/libmoar.so)
==9818== by 0x41AF42C: uv__io_close (in /home/dogbert/repos/rakudo/install/lib/libmoar.so)
gisted output here: gist.github.com/dogbert17/dca0295c...e19a6f8279 15:36
dalek arVM/wip-tile-no-template: f33b0ee | brrt++ | 3rdparty/dynasm:
Really ignore minilua
21:55
arVM/even-moar-jit: bbe01c2 | brrt++ | 3rdparty/dynasm:
Really ignore minilua
21:59