01:34:05  * dan336joined
02:37:34  * dan336quit (Quit: Leaving.)
03:29:42  * dan336joined
04:35:39  * dan336quit (Quit: Leaving.)
06:14:16  * Something12quit (Ping timeout: 244 seconds)
06:59:08  * SkyRocknRolljoined
09:06:42  * SkyRocknRollquit (Ping timeout: 272 seconds)
11:17:52  * erlbot--quit (Remote host closed the connection)
11:18:37  * erlbot--joined
13:30:34  <rphillips>good morning
13:48:06  <rphillips>creationix: lj_cf_os_date
13:48:12  <rphillips>is what instruments thinks is leaking
13:53:28  <rphillips>luv_setup_handle
13:53:31  <rphillips>as well
13:53:33  <rphillips>maybe
14:31:39  * dan336joined
14:58:44  <rphillips>has to be something in the http library
15:44:18  <creationix>rphillips how did you get instruments to tell you that?
15:45:43  <rphillips>attached instruments to the luvi process
15:45:46  <rphillips>and ran the wrk tool
15:45:54  <rphillips>i don't think the leak is in luvi though
15:46:06  <rphillips>i'm betting it's something in the http module
15:46:09  <rphillips>in luvit
16:00:38  <creationix>I think lj_cf_os_date is used by the http server (for the Date header), but if luv_setup_handle had a leak, we'd see it all over the place
16:04:27  <rphillips>yeah, it might be the handle not being unref'ed
16:40:11  <rphillips>hmm
16:57:00  <rphillips>creationix: i added a setInterval to net.lua
16:57:10  <rphillips>to dump out handle list with uv.walk
16:57:21  <creationix>is it leaking handles?
16:57:26  <rphillips>i'm not sure
16:57:26  <creationix>good idea btw
16:57:38  <rphillips>it started two interval timers
16:57:54  <rphillips>perhaps the require cache has a bug
16:58:16  <rphillips>+local i = 0
16:58:19  <rphillips>+timer.setInterval(5000, function()
16:58:21  <rphillips>+ p(string.format('*** walk start %d ***', i))
16:58:23  <rphillips>+ uv.walk(p)
16:58:25  <rphillips>+ p(string.format('*** walk end %d ***', i))
16:58:27  <rphillips>+ i = i + 1
16:58:29  <rphillips>+end)
17:00:54  <rphillips>https://www.evernote.com/l/AAk0xFxu_I5COLaxe5G9TS3TL7rxBCB7j8w
17:01:07  <rphillips>it's global to the module
17:01:55  <creationix>interesting
17:02:32  <rphillips>very. i thought i was seeing double for a second
17:04:15  <creationix>I don't see that https://gist.github.com/creationix/01d788dfea9e69c46d53
17:04:21  <creationix>where did you add the timer
17:07:43  <rphillips>creationix: line 220 of net.lua
17:08:00  <rphillips>right before the socket:destroy function
17:08:32  <creationix>yeah, that should be global
17:11:28  <rphillips>p('net.lua') does get printed twice
17:11:33  <rphillips>weird
17:13:35  <creationix>I can't reproduce that
17:17:02  <creationix>well, it's not leaking handles (not that uv.walk can see at least)
17:17:34  <rphillips>rphillips/double_import
17:17:45  <rphillips>./luvit examples/http-server.lua
17:17:55  <rphillips>prints out net.lua twice for me on OSX
17:18:00  <rphillips>clean luvit checkout on master
17:20:58  <creationix>found it!
17:21:08  <creationix>it only reproduces if loading net from the zip archive
17:21:15  <creationix>when running from disk, it doesn't double load
17:21:20  <rphillips>ah hah!
17:23:51  * DarkGodjoined
17:31:18  * hdmsjoined
17:34:34  <creationix>the resolve algorithm is getting things sometimes wrong causing the require cache to not work
17:35:00  <creationix>the same file is keyed as both /Users/tim/luvit/luvit/deps/net.lua and /Users/tim/luvit/deps/net.lua
17:39:34  <rphillips>yeah, i see the same thing
17:39:46  <rphillips>tries the bundle first, then tries the local filesystem
17:43:55  <creationix>bundle.base is wrong
17:44:06  <creationix>it's '/Users/tim/luvit/luvit' for me
17:44:14  <creationix>I think that's set by luvi
17:54:21  <creationix>hmm, that's actually not wrong, it's just treating the luvi binary like a folder since it has a zip inside it
17:55:04  <creationix>it's a logical error in our require resolution logic
17:55:55  <creationix>the question is why one require uses the deps folder on disk and another require falls through to the built-ins in the bundle
17:56:09  <creationix>I would think both would resolve to the same place
17:56:35  <creationix>(but they are two different files, one is on disk, the other is inside a zip)
18:04:40  <creationix>but good news is the double require bug only happens because you're in the luvit folder
18:04:59  <rphillips>right
18:05:03  <creationix>if you move the example outside the luvit tree it won't happen
18:05:57  <rphillips>hmm
18:06:25  <creationix>rphillips, do you know why we load dns in luvit's main init.lua?
18:06:42  <creationix>why not just loadResolver when dns is required the first time?
18:08:49  <creationix>since it's loaded from init.lua, the base path is already inside the bundle so it looks there first
18:09:05  <creationix>but later when the example on disk loads net, it looks on the disk first and finds it there
18:09:49  <creationix>should we look in the first always and ignore modules on disk that match/conflict?
18:09:57  <creationix>*look in the bundle
18:10:47  <rphillips>yeah, looking in the bundle first
18:10:50  <rphillips>makes some sense
18:12:36  <creationix>node looks internal first btw
18:13:07  <creationix>looking on disk first is more powerful, but as we've seen can be confusing when running a luvi app from it's source folder
18:13:56  * DarkGodquit (Remote host closed the connection)
18:24:56  <creationix>rphillips https://github.com/luvit/luvit/pull/822
18:25:11  * travis-cijoined
18:25:12  <travis-ci>luvit/luvit#2590 (require-internal-first - d9d556d : Tim Caswell): The build has errored.
18:25:12  <travis-ci>Change view : https://github.com/luvit/luvit/commit/d9d556d65ae5
18:25:12  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/88179762
18:25:12  * travis-cipart
18:26:12  <creationix>hmm, still have that segfault on the thread test
18:28:50  * travis-cijoined
18:28:51  <travis-ci>luvit/luvit#2590 (require-internal-first - d9d556d : Tim Caswell): The build passed.
18:28:51  <travis-ci>Change view : https://github.com/luvit/luvit/commit/d9d556d65ae5
18:28:51  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/88179762
18:28:51  * travis-cipart
18:33:19  <creationix>yeah, using instruments looks like the C side is clean
18:33:32  <creationix>maybe a couple bytes leaked in date, hard to tell
18:33:43  <creationix>it must be lua tables leaking
18:35:43  <rphillips>hmm yeah. doesn't fix the http module
18:35:48  <rphillips>leak
18:36:15  <rphillips>we could load the resolver when needed
18:38:43  <creationix>rphillips, this might help find the leak https://github.com/cloudwu/lua-snapshot
18:38:51  <creationix>pretty primitive, but better than uv.walk
18:39:10  <creationix>it's so tiny, I might just add it to luvi
18:39:34  * dan336quit (Quit: Leaving.)
18:40:14  <rphillips>yeah, that is slick
18:40:40  * travis-cijoined
18:40:41  <travis-ci>luvit/luvit#2592 (master - 1888e7e : Tim Caswell): The build passed.
18:40:41  <travis-ci>Change view : https://github.com/luvit/luvit/compare/c8630dc89195...1888e7e8344e
18:40:41  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/88183050
18:40:41  * travis-cipart
18:58:27  <creationix>information overload
19:00:49  <creationix>rphillips https://github.com/luvit/luvi/pull/124
19:01:15  <creationix>and then test with https://gist.github.com/creationix/f2ca3b8c99131926f577
19:01:37  <rphillips>oh cool. did it work?
19:01:48  <rphillips>i got a Must require in main thread
19:01:50  <rphillips>error
19:03:48  * travis-cijoined
19:03:49  <travis-ci>luvit/luvi#778 (snapshot - b905818 : Tim Caswell): The build passed.
19:03:50  <travis-ci>Change view : https://github.com/luvit/luvi/commit/b905818768f2
19:03:50  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/88187582
19:03:50  * travis-cipart
19:05:06  <creationix>rphillips, yeah you can't use it in the repl
19:05:10  <creationix>the repl is in a coroutine
19:05:29  <creationix>I get 80 new heap objects with every request
19:05:42  <creationix>though I figure some of them might get collected later
19:05:52  <creationix>maybe use timeouts before snapshotting
19:06:57  <creationix>yep, deferring with a timeout gives me 48 new heap objects every request
19:07:23  <creationix>updated gist https://gist.github.com/creationix/f2ca3b8c99131926f577
19:10:31  <creationix>we need a way to turn this data into a tree to find the roots
19:18:11  * travis-cijoined
19:18:12  <travis-ci>luvit/luvit#2589 (rphillips/double_import - ba7f1a5 : Ryan Phillips): The build has errored.
19:18:12  <travis-ci>Change view : https://github.com/luvit/luvit/commit/ba7f1a5e69a7
19:18:12  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/88163439
19:18:12  * travis-cipart
19:20:16  <creationix>we're loosing about 13Kb of lua heap on every request
19:23:44  <creationix>I'm pretty sure it's the timeout handler leaking it's closure
19:29:29  <creationix>rphillips, yep. It's the onExit. Comment it out here and the leak goes away https://github.com/luvit/luvit/blob/master/deps/http.lua#L337
19:29:42  <creationix>I have no idea what that exit handler is for though
19:38:26  * dan336joined
19:38:30  <creationix>https://github.com/luvit/luvit/pull/823
19:39:01  * travis-cijoined
19:39:02  <travis-ci>luvit/luvit#2593 (fix-exit-leak - c5e6031 : Tim Caswell): The build passed.
19:39:02  <travis-ci>Change view : https://github.com/luvit/luvit/commit/c5e6031b91f1
19:39:02  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/88194756
19:39:02  * travis-cipart
19:47:24  <creationix>interesting, windows doesn't seem to have snprintf https://ci.appveyor.com/project/racker-buildbot/luvi/build/1.0.592/job/cd40bscs69luj314
19:52:26  <daurnimator>creationix: it doesn't have a lot of things :P
19:52:45  <creationix>I guess that's part of c99.
19:53:20  * travis-cijoined
19:53:21  <travis-ci>luvit/luvi#783 (snapshot - b656dde : Tim Caswell): The build passed.
19:53:21  <travis-ci>Change view : https://github.com/luvit/luvi/compare/a1dd2f15f7d6...b656dde7c8f4
19:53:21  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/88197409
19:53:21  * travis-cipart
19:53:41  <daurnimator>creationix: they have it as _snprintf
19:53:52  <creationix>that's not quite the same thing though
19:54:54  <torque>visual studio 2015 has snprintf
19:55:03  <daurnimator>yeah. you also need to null terminator yourself with _snprintf
19:55:10  <creationix>yep yep
19:55:20  <creationix>appveyor must be using an older vs
19:55:29  <creationix>which is fine, not everyone building luvi will have the latest version
19:56:05  <daurnimator>just say you need 2015 to build on windows
19:56:14  <daurnimator>windows people rarely compile anyway
20:07:04  <creationix>alright, got it compiling on appveyor
20:07:13  * travis-cijoined
20:07:14  <travis-ci>luvit/luvi#784 (snapshot - 2c0929d : Tim Caswell): The build passed.
20:07:15  <travis-ci>Change view : https://github.com/luvit/luvi/compare/b656dde7c8f4...2c0929d6d722
20:07:15  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/88199959
20:07:15  * travis-cipart
20:11:00  * travis-cijoined
20:11:01  <travis-ci>luvit/luvi#785 (master - 730d0ca : Tim Caswell): The build passed.
20:11:01  <travis-ci>Change view : https://github.com/luvit/luvi/compare/9912d97c933b...730d0ca497ab
20:11:01  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/88200636
20:11:01  * travis-cipart
20:39:33  <rphillips>uhm
20:39:36  <rphillips>https://github.com/luvit/luvit/blob/master/deps/http.lua#L337
20:39:40  <rphillips>shouldn't that line be deleted?
20:39:43  <rphillips>that doesn't look kosher
20:42:35  <creationix>rphillips, my pr isn't merged yet https://github.com/luvit/luvit/pull/823
20:55:46  <rphillips>hmm, it's still leaking
21:21:11  <creationix>rphillips, leaking with my PR applied?
21:24:58  <rphillips>yeah
21:35:42  <creationix>rphillips, did you add a collectgarbage?
21:35:55  <creationix>the GC will use lots of memory before collecting otherwise
21:36:10  <rphillips>yeah
21:36:31  <creationix>strange
21:40:29  <creationix>hmm, maybe the collectgarbage() just slowed it down enough it looked fixed
21:40:41  <creationix>I ran it for 60 seconds and it only used 13mb
21:42:07  <rphillips>+ local gcCollect = uv.new_prepare()
21:42:09  <rphillips>+ uv.prepare_start(gcCollect, function() collectgarbage('step') end)
21:42:11  <rphillips>+ uv.unref(gcCollect)
21:42:12  <rphillips>i put this into init.lu
21:42:15  <rphillips>init.lua
21:54:19  <creationix>I'm not step is fast enough. Doing a full GC on every request seems to keep it stable (though really slow)
22:29:42  <rphillips>k
22:29:57  <rphillips>exactly the reason why we didn't add auto gc into luvit
23:20:25  * Something12joined
23:59:48  * dan336quit (Quit: Leaving.)