Time |
Nick |
Message |
00:56 |
|
TimToady joined #moarvm |
01:27 |
|
Ven`` joined #moarvm |
01:54 |
|
ilbot3 joined #moarvm |
01:54 |
|
Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at http://irclog.perlgeek.de/moarvm/today |
06:10 |
|
domidumont joined #moarvm |
08:25 |
|
robertle joined #moarvm |
08:41 |
jnthn |
morning o/ |
08:42 |
nwc10 |
good *, jnthn |
08:45 |
|
mtj_ joined #moarvm |
08:53 |
lizmat |
jnthn++ # blog post |
09:20 |
|
zakharyas joined #moarvm |
10:20 |
dogbert17 |
will the new scheduler make an entrance today? |
10:22 |
dogbert17 |
and/or should we merge the new libuv? |
10:23 |
jnthn |
dogbert17: New scheduler already merged :) |
10:23 |
jnthn |
And yeah, now is a good time on the new libuv |
10:24 |
dogbert17 |
oh, I missed that merge |
10:25 |
jnthn |
Yay, I seem to have a working async locking mechanism |
10:25 |
jnthn |
https://gist.github.com/jnthn/6f4a2258092a7fac7f80056a982e8003 |
10:25 |
lizmat |
dogbert17: also looking forward to new libuv |
10:26 |
lizmat |
.oO( newer is betterder, right? ) |
10:26 |
lizmat |
jnthn: s/hich/which |
10:26 |
dogbert17 |
lizmat: let's hope so :) |
10:26 |
Geth |
¦ MoarVM: bbfb436f3e | (Jan-Olof Hendig)++ | 3rdparty/libuv |
10:26 |
Geth |
¦ MoarVM: Bump libuv to ver. 1.14.1 |
10:26 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bbfb436f3e |
10:26 |
Geth |
¦ MoarVM: 5684e4f366 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3rdparty/libuv |
10:26 |
Geth |
¦ MoarVM: Merge pull request #682 from dogbert17/update-libuv |
10:26 |
Geth |
¦ MoarVM: |
10:26 |
Geth |
¦ MoarVM: Bump libuv to ver. 1.14.1 |
10:26 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5684e4f366 |
10:26 |
dogbert17 |
cool |
10:27 |
lizmat |
dogbert17: should I do an nqp/rakudo bump, or is that too early ? |
10:28 |
dogbert17 |
wait a bit, I wonder if this went the way I hoped, hmm |
10:28 |
* jnthn |
is doing a local build |
10:28 |
jnthn |
It all looks sensible so far: on pull, I ended up with an update to the submodule, and when it built MoarVM it rebuilt libuv |
10:29 |
jnthn |
Onto Rakudo build now |
10:29 |
lizmat |
jnthn: what is the significance of "= Holder" in "has Holder $!holder = Holder" ? |
10:29 |
jnthn |
N |
10:29 |
jnthn |
lizmat: Variables must be explicitly initialized if you use cas |
10:29 |
lizmat |
ah, ok |
10:30 |
jnthn |
Thanks to our various bits of laziness to avoid allocations |
10:30 |
jnthn |
Which makes me wonder if those are really a good idea :P |
10:30 |
dogbert17 |
yeah, I was scared at first, after doing a git pull, and I failed to see the new files |
10:30 |
dogbert17 |
but now they're there :) |
10:31 |
jnthn |
Yeah. spectesting but so far so good |
10:31 |
jnthn |
Rakudo test passed |
10:31 |
* dogbert17 |
also spectesting :) |
10:31 |
lizmat |
jnthn: since you're using nqp in the gist, is there a reason you use =:= instead of nqp::eqaddr ? |
10:32 |
jnthn |
'cus I trust in inlining :P |
10:32 |
dogbert17 |
jnthn: suspect you have more cores than I have on my $work comp (4) |
10:32 |
jnthn |
Also I find code full of nqp:: ops hard to read |
10:32 |
jnthn |
And hard to read is the last thing I want when implementing a lock-free data structure :P |
10:32 |
lizmat |
well, in my experience =:= badly inlines because of its megamorphicness |
10:33 |
lizmat |
or has that changed ? |
10:33 |
jnthn |
It should be better now |
10:33 |
jnthn |
In theory at least :) |
10:33 |
jnthn |
In practice would have to check :) |
10:34 |
jnthn |
dogbert17: spectest ok here |
10:36 |
lizmat |
Just tested: nqp::eqaddr is about 1.6x faster, but I think that's mainly because it needs do boolification |
10:36 |
lizmat |
*it being =:= |
10:36 |
jnthn |
Yeah |
10:37 |
jnthn |
I can live with that for now :) |
10:44 |
dogbert17 |
jnthn: looks good here in 32 bit land as well :) |
10:45 |
dogbert17 |
quite a few changes since 1.8, https://github.com/libuv/libuv/blob/v1.x/ChangeLog |
10:48 |
jnthn |
Indeed |
10:49 |
* dogbert17 |
wonders if Cygwin will work now |
11:01 |
Geth |
¦ MoarVM: 6ef763b3a8 | MasterDuke17++ | 2 files |
11:01 |
Geth |
¦ MoarVM: Add MVM_fixed_size_realloc |
11:01 |
Geth |
¦ MoarVM: |
11:01 |
Geth |
¦ MoarVM: Also add an _at_safepoint version. |
11:01 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6ef763b3a8 |
11:01 |
Geth |
¦ MoarVM: ece0c5f7c4 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files |
11:01 |
Geth |
¦ MoarVM: Merge pull request #688 from MasterDuke17/add_realloc_to_fsa |
11:01 |
Geth |
¦ MoarVM: |
11:01 |
Geth |
¦ MoarVM: Add MVM_fixed_size_realloc |
11:01 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ece0c5f7c4 |
11:07 |
jnthn |
dogbert17: Maybe, though I don't care to be the person who finds out :-) |
11:08 |
jnthn |
I'm sure somebody will try it :) |
11:17 |
|
lizmat joined #moarvm |
11:24 |
|
leont joined #moarvm |
12:00 |
|
AlexDaniel joined #moarvm |
12:31 |
|
travis-ci joined #moarvm |
12:31 |
travis-ci |
MoarVM build errored. Jonathan Worthington 'Merge pull request #688 from MasterDuke17/add_realloc_to_fsa |
12:31 |
travis-ci |
https://travis-ci.org/MoarVM/MoarVM/builds/276801107 https://github.com/MoarVM/MoarVM/compare/5684e4f3668d...ece0c5f7c4b1 |
12:31 |
|
travis-ci left #moarvm |
12:32 |
|
buggable joined #moarvm |
12:37 |
jnthn |
apt install error, it seems |
13:11 |
|
buggable joined #moarvm |
13:20 |
|
buggable joined #moarvm |
14:45 |
|
erratum joined #moarvm |
15:21 |
|
buggable joined #moarvm |
15:23 |
|
buggable joined #moarvm |
15:24 |
|
Geth_ joined #moarvm |
15:27 |
|
Geth_ joined #moarvm |
15:29 |
|
Geth_ joined #moarvm |
15:30 |
|
Geth_ joined #moarvm |
15:44 |
|
buggable joined #moarvm |
15:50 |
|
buggable joined #moarvm |
15:51 |
|
buggable joined #moarvm |
16:28 |
Geth |
¦ MoarVM: 1afedf5188 | (Jonathan Worthington)++ | src/core/threads.c |
16:28 |
Geth |
¦ MoarVM: Stash native thread ID after GC unblock |
16:28 |
Geth |
¦ MoarVM: |
16:28 |
Geth |
¦ MoarVM: Otherwise the thread object inside of the thread context may be an |
16:28 |
Geth |
¦ MoarVM: outdated pointer due to an ongoing GC run, and thus the stored native |
16:28 |
Geth |
¦ MoarVM: thread ID will be to an invalid location. |
16:28 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1afedf5188 |
16:36 |
Geth |
¦ MoarVM: 1959f2ff2e | (Jonathan Worthington)++ | 3 files |
16:36 |
Geth |
¦ MoarVM: Make native callback thread finding more robust |
16:36 |
Geth |
¦ MoarVM: |
16:36 |
Geth |
¦ MoarVM: While the bug fixed in the commit prior to this one was the major |
16:36 |
Geth |
¦ MoarVM: cause of failing to find the correct thread, there was also a race on |
16:36 |
Geth |
¦ MoarVM: looking through the thread list. Fix that here also. |
16:36 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1959f2ff2e |
16:37 |
|
Ven`` joined #moarvm |
16:51 |
Geth |
¦ MoarVM: eeb664ea65 | (Jonathan Worthington)++ | 4 files |
16:51 |
Geth |
¦ MoarVM: Factor out callback thread finding |
16:51 |
Geth |
¦ MoarVM: |
16:51 |
Geth |
¦ MoarVM: This means the fixed version is now shared between both the dyncall |
16:51 |
Geth |
¦ MoarVM: and libffi codepaths. |
16:51 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eeb664ea65 |
16:52 |
nine |
Looks quite nice now :) |
16:52 |
|
robertle joined #moarvm |
16:53 |
jnthn |
Shoulda probably have had it factored out that way in the first place :) |
17:03 |
|
Ven`` joined #moarvm |
17:06 |
ugexe |
looks like libuv 1.14 added a uv_fs_filecopy(), which uses the CopyFile API on windows. Maybe MVM_file_copy could use that? |
17:06 |
ugexe |
er, _copyfile |
17:07 |
ugexe |
https://github.com/MoarVM/MoarVM/blob/df404cab9899bec5ca0cfc174dcfe3596cd38abe/src/io/fileops.c#L122 (note the comment mentions the CopyFile api) |
17:17 |
|
Skarsnik joined #moarvm |
17:26 |
|
buggable joined #moarvm |
17:43 |
|
Skarsnik_ joined #moarvm |
17:50 |
ugexe |
i am testing such a change on various os |
18:46 |
|
buggable joined #moarvm |
18:55 |
|
committable6 joined #moarvm |
18:55 |
|
bloatable6 joined #moarvm |
18:55 |
|
coverable6 joined #moarvm |
18:55 |
|
nativecallable6 joined #moarvm |
18:55 |
|
quotable6 joined #moarvm |
18:55 |
|
greppable6 joined #moarvm |
18:55 |
|
releasable6 joined #moarvm |
18:55 |
|
bisectable6 joined #moarvm |
18:55 |
|
unicodable6 joined #moarvm |
18:55 |
|
squashable6 joined #moarvm |
18:55 |
|
evalable6 joined #moarvm |
18:55 |
|
benchable6 joined #moarvm |
18:55 |
|
statisfiable6 joined #moarvm |
19:08 |
AlexDaniel |
⚠ Rakudo SQUASHathon 2017-10-07 https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day |
19:15 |
Geth_ |
¦ moarvm.org: a6a039d539 | jnthn++ | 2 files |
19:15 |
Geth_ |
¦ moarvm.org: Update for 2017.09 release |
19:15 |
Geth_ |
¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/a6a039d539 |
19:19 |
jnthn |
Goodness, a lot got done in the last couple of releases. |
19:22 |
* jnthn |
didn't even do very much last month, and still loads got done :D |
19:22 |
jnthn |
Really nice work, everyone <3 |
19:22 |
lizmat |
yeah, it really adds up :-) |
19:34 |
nine |
Oh... when ncinvoke_o is JITed, the arg_* ops are pretty much superfluous. They'd just copy registers. I can instead just access the WORK registers directly. Just like my previous implementation did. |
19:37 |
nine |
So I'd end up with pretty much the same assembly code as the previous implementation. But now I don't need conventions or special cases in spesh :) |
19:40 |
moritz |
convergence! |
19:40 |
nine |
I just love these moments when things come together so beautifully :) |
19:41 |
* lizmat |
lights a cigar |
19:42 |
lizmat |
https://www.youtube.com/watch?v=XwozVKOkzz4 |
19:43 |
nine |
lizmat: exactly :) |
19:44 |
jnthn |
nine: Yes :-) |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: 48a5823b31 | (Stefan Seifert)++ | 4 files |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: Bring back JITing of ncinvoke_o |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: Since at this stage the code calling the ncinvoke_o op cannot change anymore, |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: we can access the WORK registers directly, saving the copying of those to |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: tc->cur_frame->args. |
19:46 |
Geth |
¦ MoarVM/jit_nativecall: review: https://github.com/MoarVM/MoarVM/commit/48a5823b31 |
19:47 |
nine |
So what looked like loads of work yesterday turned out to be less than five minutes today. Good thing, cause I spent most of my evening watching youtube videos about theoretical physics ;) |
19:48 |
moritz |
heh, for me it's astronomy :-) |
19:51 |
[Coke] |
numberphile and twitch, here. :) |
19:55 |
moritz |
https://www.youtube.com/playlist?list=PL8dPuuaLjXtPAJr1ysd5yGIyiSFuh0mIL if anybody needs inspiration :-) |
20:12 |
nine |
Ok, numbers look the same as the previous version for 10000 iterations and apparently better than before for 100000. |
20:15 |
nine |
Actually I measured 100_000 vs. 1000_000 iterations |
20:18 |
timotimo |
any benchmarks to see how pre vs post jit-nativecall performance is? |
20:19 |
nine |
Indeed, results seem consistent. So far I've got 44.221s for the latest code vs. 45.530s for the cheating one (best runs of several with 1_000_000 iterations) |
20:20 |
Skarsnik |
it's something ^^ |
20:20 |
timotimo |
what does your benchamrk look like? csv with inline::perl5? |
20:20 |
nine |
timotimo: yes, csv-ip5xs.pl |
20:21 |
Skarsnik |
You could run a parse-html of Gumbo on a big html file (with lot of element) |
20:21 |
Skarsnik |
there is a function called for each html elements |
20:22 |
nine |
Numbers with the new JIT turned off coming up soon. Btw. keep in mind that so far only native calls with arguments that are integers or pointers are JITed. |
20:22 |
nine |
No strings and no rw args. |
20:22 |
Skarsnik |
hm will be Str |
20:22 |
timotimo |
that's a big percentage of 'em |
20:23 |
timotimo |
if by pointers you include structs for example |
20:23 |
nine |
Inline::Perl5 uses rw args on several calls (invoke among them) and CSV is about strings. So I guess about half of the calls are actually JIT compiled. |
20:23 |
* jnthn |
wonders what this'll do to IO::Socket::Async::SSL perf :) |
20:24 |
Skarsnik |
hm why Str can't be JIT? |
20:24 |
timotimo |
just won't do it yet |
20:24 |
jnthn |
Skarsnik: I think it's just "not done yet", not "can't be" :) |
20:24 |
Skarsnik |
Hoo alright |
20:24 |
nine |
Skarsnik: unmarshalling of strings is more complicated as I need to call C functions. So I can't do it in the middle of setting up arguments for the actual function call. |
20:25 |
nine |
So yes, needs some more work. A simple first step would be to support one string argument by simply processing it first, before the other arguments. |
20:25 |
timotimo |
jnthn: should spesh be able to turn wval + getattr_o into a faster op? i was looking at permutations the other day and it refered to $!next a few times and had a whole bunch of code for it each time |
20:25 |
timotimo |
even though i think it should have been able to use a sp_p6oget_o or what it's called for it |
20:26 |
jnthn |
Much of the time it can be turned into a spesh op like that, yes |
20:26 |
jnthn |
Check the facts to see why it can't be in this case, I guess ;) |
20:26 |
jnthn |
*:) |
20:26 |
timotimo |
right |
20:30 |
timotimo |
huh, 0 flags |
20:32 |
nine |
47.397s without JITing. So JITing gives a 7 % speedup. |
20:32 |
timotimo |
sp_getarg_o r9(2), liti16(0) |
20:32 |
timotimo |
r9(2): usages=1, flags=13 KnTyp Dcntd Concr DeadWriter |
20:32 |
timotimo |
that doesn't fit, does it? |
20:34 |
timotimo |
the other registers that get their values from this one don't have DeadWriter |
20:35 |
timotimo |
oh, could it be ... |
20:35 |
timotimo |
r0(3) is being merged together by, among others, itself |
20:35 |
timotimo |
we probably don't have anything in the code for that to not say "oh, we know nothing about this!" |
20:43 |
timotimo |
well, that certainly did nothing at all |
20:44 |
timotimo |
we would pobably have to iterate to a fix point to get phi merged facts proper in jump-backwards-situations? |
20:50 |
Geth |
¦ MoarVM/jit_nativecall: 18 commits pushed by (Stefan Seifert)++ |
20:50 |
Geth |
¦ MoarVM/jit_nativecall: review: https://github.com/MoarVM/MoarVM/compare/48a5823b31...0d162dbf1c |
20:52 |
timotimo |
hm. a PHI with arguments we have no facts for, but where we know that they are written to by a PHI, those could benefit from doing a full-graph search i think |
20:53 |
timotimo |
except we have the writers directly available right then and there |
20:54 |
* timotimo |
rolls up imaginary sleeves |
21:01 |
ugexe |
libuv uv_fs_copyfile does not use O_TRUNC on the destination handle, copying a file with "A" into a file with "XXX" results with "AXX" |
21:02 |
ugexe |
on linux. on osx it results in "A" |
21:05 |
samcv |
i can't seem to compile moarvm on freebsd |
21:05 |
samcv |
it's failing when trying to compile libatomic |
21:06 |
timotimo |
maybe we need a version bump in libatomic for that? |
21:06 |
samcv |
yeah hold on. trying to build again without -j |
21:07 |
samcv |
ok it didn't fail that. i get undefined reference to uv__hrtime |
21:08 |
samcv |
looks like it was a build parallization issue on freebsd with libatomic. but i am getting it not linking properly |
21:11 |
Skarsnik |
I wonder if google has arm VM x) |
21:41 |
lizmat |
and yet another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/09/18/2017-38-color-me-booked/ |
21:44 |
samcv |
lizmat++ |
21:46 |
lizmat |
samcv: any thoughts about Reini's blog posr re Perl 6 ? |
21:47 |
lizmat |
it feels he's not up to date with all of your latest work |
21:51 |
samcv |
yeah |
21:52 |
samcv |
other than namedropping perl6 it was a good article |
21:52 |
samcv |
just need to delete one word and then add a paragraph saying perl 6 is the best :) |
21:52 |
lizmat |
well, please tell him :-) You're the person of authority here :-) |
21:54 |
jnthn |
Given Perl 6 normalizes everything at input, I'm not sure why it'd not be doing this right |
22:07 |
MasterDuke |
https://i.imgur.com/9YzmQ1F.png heaptrack report for that script that had high memory use a little while ago |
22:09 |
MasterDuke |
https://imgur.com/zD2CfJm ~10 days ago to compare |
22:12 |
jnthn |
Nice reduction :) |
22:12 |
jnthn |
New scheduler can be thanked for starting less threads :) |
22:13 |
MasterDuke |
yeah, quite dramatic |
22:14 |
MasterDuke |
AlexDaniel: ^^^, might be time to rebuild rakudo on the *able server |
22:28 |
jnthn |
rest time o/ |
22:35 |
Geth |
¦ MoarVM: 43d6af05db | (Samantha McVey)++ | .appveyor.yml |
22:35 |
Geth |
¦ MoarVM: Try and enable and build matrix with Appveyor |
22:35 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/43d6af05db |
22:41 |
Geth |
¦ MoarVM: 2824dcf8fc | (Samantha McVey)++ | .appveyor.yml |
22:41 |
Geth |
¦ MoarVM: Trigger Appveyor build |
22:41 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2824dcf8fc |
22:41 |
samcv |
yay it works! |
22:41 |
samcv |
https://ci.appveyor.com/project/samcv/moarvm-35u74 |
22:42 |
samcv |
msvc 2015 and 2017 x64 and x86 matrix |
22:42 |
samcv |
\o/ |
22:45 |
MasterDuke |
nice |
22:47 |
samcv |
uh windows is failing as well linking libuv |
22:50 |
samcv |
freebsd too |
22:56 |
samcv |
yeah reverting the libuv bump fixes building on freebsd |
22:58 |
MasterDuke |
that sucks. anything in libuv release notes about freebsd? |
23:05 |
samcv |
well it fails on windows too |
23:06 |
AlexDaniel |
MasterDuke: botacalypse again? I just did that todayy… |
23:07 |
MasterDuke |
think of the ram savings! |
23:07 |
AlexDaniel |
are you thinking that things like this will not leak anymore |
23:08 |
AlexDaniel |
c: eonhuotueh say 42 |
23:08 |
committable6 |
AlexDaniel, ¦eonhuotueh: «Cannot find this revision (did you mean “Karlsruhe”?)» |
23:08 |
AlexDaniel |
c: eonhuotueh say 42 |
23:08 |
committable6 |
AlexDaniel, ¦eonhuotueh: «Cannot find this revision (did you mean “Karlsruhe”?)» |
23:08 |
AlexDaniel |
c: eonhuotueh say 42 |
23:08 |
committable6 |
AlexDaniel, ¦eonhuotueh: «Cannot find this revision (did you mean “Karlsruhe”?)» |
23:08 |
MasterDuke |
leak less |
23:08 |
AlexDaniel |
c: foo say 42 |
23:08 |
committable6 |
AlexDaniel, ¦foo: «Cannot find this revision (did you mean “all”?)» |
23:08 |
AlexDaniel |
c: abc242 say 42 |
23:08 |
committable6 |
AlexDaniel, ¦abc242: «Cannot find this revision (did you mean “b1c412a”?)» |
23:08 |
AlexDaniel |
c: abc242 say 42 |
23:08 |
committable6 |
AlexDaniel, ¦abc242: «Cannot find this revision (did you mean “b1c412a”?)» |
23:08 |
AlexDaniel |
c: abc242 say 42 |
23:08 |
committable6 |
AlexDaniel, ¦abc242: «Cannot find this revision (did you mean “b1c412a”?)» |
23:08 |
AlexDaniel |
but even this is no longer leaking |
23:09 |
AlexDaniel |
greppable6: password |
23:09 |
greppable6 |
AlexDaniel, https://gist.github.com/a6099a830ea3271c6458de894a987a51 |
23:09 |
AlexDaniel |
greppable6: password |
23:09 |
greppable6 |
AlexDaniel, https://gist.github.com/ea12f53147bae44a265d85e65ad3fdd9 |
23:09 |
AlexDaniel |
OK, this does. |
23:10 |
samcv |
libuv compiles fine if i cd into 3rdparty/libuv and run ./autogen.sh and then ./configure then make |
23:13 |
ugexe |
windows fix looks easy enough |
23:16 |
samcv |
did they add a new file or something? |
23:17 |
samcv |
looks like i need to add a file for bsd |
23:17 |
|
quotable6 joined #moarvm |
23:17 |
|
coverable6 joined #moarvm |
23:17 |
|
nativecallable6 joined #moarvm |
23:18 |
|
greppable6 joined #moarvm |
23:18 |
|
releasable6 joined #moarvm |
23:18 |
|
bloatable6 joined #moarvm |
23:18 |
|
committable6 joined #moarvm |
23:18 |
|
bisectable6 joined #moarvm |
23:18 |
|
evalable6 joined #moarvm |
23:18 |
|
statisfiable6 joined #moarvm |
23:18 |
|
unicodable6 joined #moarvm |
23:18 |
|
squashable6 joined #moarvm |
23:18 |
|
benchable6 joined #moarvm |
23:19 |
|
committable6 joined #moarvm |
23:19 |
|
greppable6 joined #moarvm |
23:19 |
AlexDaniel |
MasterDuke: I see no change |
23:19 |
AlexDaniel |
at least nothing noticeable to human eye |
23:22 |
Geth |
¦ MoarVM: ugexe++ created pull request #694: Pass user32 lib to build on windows |
23:22 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/694 |
23:22 |
Geth |
¦ MoarVM: dfbf9df7b6 | (Samantha McVey)++ | build/Makefile.in |
23:22 |
Geth |
¦ MoarVM: Fix FreeBSD build by adding new libuv file to Makefile.in |
23:22 |
Geth |
¦ MoarVM: |
23:22 |
Geth |
¦ MoarVM: FreeBSD build broke after bumping libuv. Add the new file to Makefile.in |
23:22 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dfbf9df7b6 |
23:22 |
samcv |
yay bulid fixed |
23:22 |
samcv |
going thing i decided to install freebsd |
23:32 |
MasterDuke |
samcv: heaptrack thinks MVM_string_join (src/string/ops.c:1704) leaks. see anything obvious? |
23:32 |
samcv |
uh |
23:33 |
samcv |
i don't think it allocates anything that isn't attached to a string afaik |
23:33 |
samcv |
do we know where it is donig the allocation? |
23:33 |
MasterDuke |
1704 is where heaptrack thinks it's happening |
23:35 |
samcv |
well that gets attached to a string. maybe the GC just hasn't reclaimed it yet? idk |
23:35 |
MasterDuke |
hm. i was using --full-cleanup, but i guess i can try adding some nqp::force_gc()'s and see if that changes anything |
23:36 |
ugexe |
https://github.com/MoarVM/MoarVM/pull/694 fixes the windows build |
23:39 |
Geth |
¦ MoarVM: cabfefe2f2 | (Nick Logan)++ (committed using GitHub Web editor) | build/setup.pm |
23:39 |
Geth |
¦ MoarVM: Pass user32 lib to build on windows |
23:39 |
Geth |
¦ MoarVM: |
23:39 |
Geth |
¦ MoarVM: See: https://github.com/libuv/libuv/commit/e51442bbc9b37dff32430c047844d9181798a9a8#diff-67e997bcfdac55191033d57a16d1408aR62 |
23:39 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cabfefe2f2 |
23:39 |
Geth |
¦ MoarVM: eabfc24273 | (Samantha McVey)++ (committed using GitHub Web editor) | build/setup.pm |
23:39 |
Geth |
¦ MoarVM: Merge pull request #694 from ugexe/patch-1 |
23:39 |
samcv |
cool. thanks ugexe |
23:39 |
Geth |
¦ MoarVM: |
23:39 |
Geth |
¦ MoarVM: Pass user32 lib to build on windows |
23:39 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eabfc24273 |
23:55 |
samcv |
--with-ffi fails on freebsd. need to fix that |