|
00:59
pyrimidine joined
01:42
vendethiel- joined
02:03
pyrimidine joined
02:28
FROGGS joined
02:31
pyrimidine joined
02:48
ilbot3 joined
03:38
pyrimidine joined
05:00
leego joined
05:03
leego joined
05:33
pyrimidi_ joined
05:55
geekosaur joined
05:57
geekosaur joined
10:31
domidumont joined
10:51
FROGGS joined
|
|||
| 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 | ||
|
12:44
Ven joined
|
|||
| 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 | |
|
14:53
dalek joined
|
|||
| 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 | ||
|
16:23
pyrimidine joined
16:41
stmuk joined
16:48
domidumont joined
16:52
domidumont joined
17:29
pyrimidine joined
17:43
Ven joined
18:12
domidumont joined
19:30
pyrimidine joined
19:45
domidumont joined
20:46
Ven joined
21:06
Ven joined
21:26
Ven joined
21:46
Ven joined
|
|||
| 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 | ||
|
22:06
Ven joined
22:26
pyrimidine joined,
Ven joined
22:37
pyrimidine joined
22:46
Ven joined
22:55
pyrimidine joined
23:06
Ven joined
23:15
pyrimidine joined
23:33
pyrimidine joined
|
|||